Tag Archives: automation

000GIT, 04 - Workflows & Automation

Automated Testing

Welcome to the NZRT Wiki Podcast. Today we’re looking at Automated Testing.

So what is automated testing and why does NZRT use it? Put simply, automated tests let you validate code changes quickly and reliably — without manually clicking through everything every time someone pushes an update. At NZRT, testing falls into three main categories, and it’s worth understanding the difference between them.

First, you have unit tests. These test individual functions in isolation, meaning any external dependencies like databases or APIs are swapped out for fakes — called mocks — so you’re only checking one small piece of logic at a time. Then there are integration tests, which go a level up and check how components actually interact with each other — think database calls and API connections working together. Finally, end-to-end tests, or E2E tests, simulate full user workflows either in a browser or a live environment. So where a unit test might check a single calculation, an E2E test walks through an entire user journey from start to finish.

A few other concepts you’ll hear mentioned. Test coverage is the percentage of your code paths that tests actually execute — NZRT aims for above eighty percent. CI integration means tests run automatically whenever you open a pull request or push a commit. And critically, if tests fail, that pull request is blocked — it cannot be merged until everything passes. Test results and coverage data are all visible through GitHub Actions.

Now, the tools NZRT uses depend on the language you’re working in. There are four main stacks. For PHP, the framework is PHPUnit and you run it with the phpunit command. For JavaScript, Jest handles both the assertions and the test run via npm test. For Python, pytest does everything — you just run pytest. And for Bash scripts, there’s a tool called bats, which works the same way — you run bats and it handles the rest.

Let’s talk about the Dolibarr custom test suite specifically. Tests live in a directory called tests, and the PHP file shown as an example is called WpSyncProductTest. It contains three test methods that give you a good picture of how tests are structured. The first checks that a product can be created — it inserts a test product and confirms the returned ID is greater than zero, meaning something was actually saved. The second test creates a product object using a specific ID, retrieves its SKU, and checks two things: that the SKU isn’t empty, and that it starts with the prefix NZRT-dash. The third test takes a product, calls a method that syncs it to Dolibarr, and then checks two outcomes — that the sync returned true, and that the product’s Dolibarr status in the database was set to the word “synced”. Together these three tests cover creation, data integrity, and a cross-system sync operation.

Running tests locally is straightforward. For PHP in the Dolibarr custom project, you change into that directory and run phpunit pointing at the tests folder. For JavaScript, it’s just npm test. For Python in the nzrt-scripts repo, you run pytest against the tests directory. And if you want a full coverage report generated as HTML, you add a coverage flag to the phpunit command and it outputs into a coverage folder you can open in a browser.

Coverage reporting is also wired into the CI pipeline. A workflow step runs phpunit with a flag that outputs coverage data in a format called Clover XML. That file is then uploaded to a service called Codecov using a GitHub Actions step — it’s tagged as unit tests and given the name codecov-umbrella. This means every time tests run in CI, coverage trends are tracked automatically over time.

If you want to dig deeper, the related topics to look at next are the CI CD Overview, GitHub Actions Workflows, and the Code Review Process — all linked from this wiki page.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000GIT, 04 - Workflows & Automation

Deployment Pipelines

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🚀 Deployment Pipelines.

If you’ve ever wondered how code travels from a developer’s laptop to a live server without breaking everything, deployment pipelines are the answer. At NZRT, these pipelines automate the process of releasing code to staging and production environments. And depending on which system you’re working with, the approach is a little different.

Let’s start with some key concepts you’ll want to understand.

First, there’s the staging environment. Think of this as a rehearsal space — it mirrors your production server so you can test changes before real users ever see them. The production environment is the live server actually serving customers. A deployment script is an automated script that pulls the latest code and restarts any services that need it. Health checks verify that a deployment actually worked — essentially asking “did everything go okay?” Rollback is your safety net: if something breaks, you revert to the previous working version.

You might also hear about blue-green deployment, where you run two identical production environments and switch traffic between them when you’re ready. Or canary deployment, where you gradually roll out a change to just a percentage of your traffic before going all in. Zero-downtime deployment means handling things like database migrations and cache updates without ever interrupting the live service.

Now let’s look at how NZRT actually deploys its two main systems.

For Dolibarr custom, the process is continuous and triggered daily. A developer creates a feature branch, runs tests, then opens a pull request to the main branch. That pull request needs at least one code review approval before it can be merged. When it’s merged — using a squash merge to keep the history clean — GitHub Actions kicks in automatically. It runs a linter to check code quality, executes tests, performs a security scan, and then deploys directly to the Dolibarr custom environment. Health checks and smoke tests confirm everything is working, and a Slack notification goes out to the team.

The standard Dolibarr deployment follows a similar flow but adds an important safety mechanism: feature flags. A developer creates a short-lived branch, ideally lasting less than three days. Any new feature is wrapped behind a feature flag that starts switched off. After tests pass and the pull request is merged, GitHub Actions runs linting, unit tests, and integration tests, then automatically deploys to production — but the feature flag stays off. The code is live but dormant.

After deployment, the team monitors error logs and performance. When they’re confident everything looks good, they enable the feature flag and monitor again for regressions. If something goes wrong, they can disable the feature flag immediately — that’s the fastest fix — or revert the commit and redeploy.

Now let’s talk about what the actual deployment script does behind the scenes. The script takes two inputs: the environment you’re targeting, either production or staging, and the version number you want to deploy. Based on those inputs, it determines which server to connect to.

It then carries out six steps over a secure connection to the target server. First, it creates a timestamped database backup, so you always have a restore point before anything changes. Second, it checks out the specified version of the code and pulls the latest files. Third, it installs PHP dependencies, skipping anything only needed for development. Fourth, it runs any database migrations that have been queued. Fifth, it flushes the cache so the server isn’t serving stale data. And sixth, it runs a health check by requesting a specific page on the server — if that request fails, the script stops immediately and reports the failure.

If you ever need to roll back, the process is straightforward. You can list all tagged releases to find the version you want to return to, then run the deploy script again pointing at that earlier version tag. If things are really urgent, you can connect directly to the server and revert the most recent commit on the spot.

That covers the full deployment pipeline picture at NZRT — from branching strategies and feature flags all the way through to the step-by-step mechanics of what happens on the server during every release.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000GIT, 04 - Workflows & Automation

Github Actions Workflows

Leave a comment

Welcome to the NZRT Wiki Podcast. Today we’re looking at ⚙️ GitHub Actions Workflows.

If you’ve ever pushed code to a GitHub repository and wondered how tests run automatically, or how your changes end up on a server without anyone manually doing it — that’s GitHub Actions at work. At NZRT, we use it across our repositories to handle linting, testing, and deployment in a consistent, automated way.

So let’s start with the basics. A GitHub Actions workflow is a configuration file written in YAML, and it lives inside a folder called dot-github slash workflows in your repository. The structure of one of these files is straightforward. You give the workflow a name, you tell it what events should trigger it — things like a push to a branch, a pull request, or a scheduled time — and then you define one or more jobs. Each job runs on a virtual machine, typically the latest version of Ubuntu, and contains a series of steps that run in order.

Now let’s look at the main workflows NZRT uses.

The first is the deploy workflow for the Dolibarr custom project. This one triggers in two situations: when you push to either the develop or main branches, or when a release is published. It has three jobs that can run depending on the context.

The first job is called lint-and-test, and it runs every time. It sets up a PHP 8.1 environment with the extensions needed for the project, installs dependencies using Composer, then runs three checks in sequence. First it scans every PHP file in the WordPress content folder to make sure the syntax is valid. Then it runs a security scan. Then it runs the full test suite using PHPUnit. If any of those steps fail, the whole workflow stops there.

The second job, deploy to staging, only runs if the branch being pushed is the develop branch, and it only starts if lint-and-test passed. It connects to the staging server over SSH using a deploy key stored as a secret, pulls the latest code, and flushes the WordPress cache. When it’s done — whether it succeeded or failed — it sends a Slack notification with the status, who triggered it, and what repository it was for.

The third job, deploy to production, works differently. It only runs when you push a version tag — something like v one-point-two-point-zero. It uses GitHub’s deployment API to register a formal deployment event, then connects to the production server via SSH, checks out the tagged version, pulls it down, flushes the cache, and exports a database backup before anything changes. After deploying, it runs two health checks against the live site to confirm it’s responding. Then it sends a Slack notification with the version number and status.

The second workflow is the Dolibarr CI workflow. This one runs on every push and every pull request — so it’s always watching. It has two jobs. The first is a linting job that checks your PHP code against the PSR12 coding standard and runs static analysis to catch type errors and other issues before they become bugs. The second job is a test job, and this one spins up an actual MySQL 8 database as part of the runner environment — it even has a health check to make sure the database is ready before the tests start. Then it installs dependencies and runs the test suite against that live database connection.

The third workflow is the NZRT Scripts deploy workflow. This one is simpler. Any time you push to the main branch of the NZRT-Scripts repository, it SSHes into the cPanel server, goes to the scripts folder, pulls the latest code from the main branch, and makes sure all shell scripts are marked as executable. Then it verifies the deploy worked by logging the most recent commit on the server.

Now, all three of these workflows rely on secrets — sensitive values like SSH keys, usernames, and ports that you never want to hard-code into a file. NZRT manages these at the organisation level in GitHub, which means they’re available to every repository without you needing to set them up repo by repo. There are three org-level secrets you need to know about. The deploy key is the SSH private key used to authenticate with the server. The deploy user is the cPanel SSH username. And the deploy port is the port number used for SSH connections. All three are stored in the organisation secrets settings page on GitHub.

If you want to dig deeper, the wiki has related notes on CI CD Overview, Automated Testing, Deployment Pipelines, and the Git Deployment page which covers cPanel-specific git setup.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.