Welcome to the NZRT Wiki Podcast. Today we’re looking at CI/CD Overview.

If you’ve ever wondered how code goes from a developer’s laptop to a live production system without someone manually clicking through a checklist at midnight, that’s exactly what CI/CD is all about. CI stands for Continuous Integration, and CD stands for Continuous Deployment. Together, they automate the testing and deployment of your code so that every change is checked, built, and shipped in a reliable, repeatable way.

Let’s break down what each part means. Continuous Integration means that every time a developer pushes a code change or opens a pull request, automated tests kick in immediately. These tests might check code style with a linter, run unit tests to make sure nothing is broken, or even run security scans to catch vulnerabilities early. The idea is that you catch problems at the point of change, not three weeks later when someone is trying to track down a mystery bug.

Continuous Deployment takes it a step further. Once the tests pass, the code is automatically deployed to the right environment. At NZRT, the general pattern is that merging into the develop branch pushes to a staging environment, while merging into main or creating a release tag triggers a production deployment.

There are five main stages in a pipeline. First, lint — which checks that the code is written cleanly and follows style rules. Second, test — which runs all the automated tests. Third, build — which compiles or packages the code into a deployable artifact. Fourth, deploy — which sends that artifact to the target environment. And fifth, verify — which confirms the deployment actually worked, usually through health checks.

There are also a few important supporting concepts to know about. Status checks mean that a pull request is blocked from merging until every pipeline stage passes. Notifications send alerts to Slack or email so the team knows right away if something succeeds or fails. Rollback gives you a quick path back to the previous working version if a deployment goes wrong. And artifacts are the saved build outputs that can be used for release distribution.

Now let’s look at how NZRT specifically uses CI/CD across its two main code areas. For the dolibarr-custom project, which handles WordPress and Dolibarr sync, the pipeline triggers on any push to main or any pull request targeting main. The tests cover PHP linting, a WordPress security scan, and checks for module conflicts. A successful pipeline deploys to the dolibarr-custom staging domain, and when you create a versioned release tag, it goes to production but requires a manual approval step before it does.

For the core Dolibarr ERP project, the setup is similar in terms of triggers and PHP linting, but it also includes unit tests and integration tests. Deployments here go straight to production immediately, but with feature flags turned off by default so new functionality can be controlled after deployment. Health checks and error rate monitoring run continuously to catch anything that slips through.

Let’s walk through the pipeline execution flow, which is shown as a diagram in the wiki. Picture a developer pushing code. That push is detected by GitHub, which triggers GitHub Actions. At that point, the pipeline splits into two parallel tasks running at the same time — the lint check and the test suite. Once both of those finish, the pipeline checks whether everything passed. If yes, it moves on to deploy and then verify, ending in a success state. If either the lint or tests failed, the pipeline stops, marks the build as failed, and automatically posts a comment on the pull request showing what went wrong. That means you get immediate, specific feedback right where you’re working.

Finally, NZRT tracks five key metrics to measure how well the CI/CD system is performing. Build time should be under five minutes for pull request checks. Test coverage should be above eighty percent on any modified code. Deployment frequency for dolibarr-custom is targeted at one to two deployments per day. Lead time — meaning the total time from a commit to it being live in production — should be under thirty minutes. And mean time to recover, which is how long it takes to roll back a bad deployment, should be under five minutes.

Those five numbers give you a clear health picture of your delivery pipeline. If build times start creeping up, or rollback takes longer than expected, those are early signals that something needs attention.

If you want to go deeper on any of this, the wiki links out to three related notes covering GitHub Actions Workflows, Automated Testing, and Deployment Pipelines specifically. Those are worth reading alongside this overview.

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