In today’s software development process, there is a constant push to deliver quality products at a rapid rate. Even more so when companies are on a leaner R&D budget, where you continuously strive to do more with less. If you do not already have an efficient CI process set up in your team, then you have come to the right page. From the experience I have gathered across multiple teams, I have tried to accommodate all the essentials you’d need to make your CI pipeline a success. CI is just not a fad, it’s a way of working.

Quality feedback before code review:

The definition of a story/task being ‘dev done’ is a question that we come across every team. CI pipelines are supposed to be designed in a way that shares functional feedback with the developer even before someone from the team decides to review the pull request. Ideally, whenever one pushes code to a remote git branch, unit+service+integration(with mock services) tests should automatically run and let them know whether the code has an impact anywhere, mainly regression. Teams can take it one step forward by automating service-level tests simultaneously and merging them into the same branch. Hot take, but I have always believed quality to be a collective responsibility and that developers in the team should take equal if not more ownership in writing service-level tests. 

Everything-in-one pipeline:

Besides the automated unit/service/integration level tests, a comprehensive CI pipeline should include steps for static code analysis looking for possible code smells, violations of coding standards set in the organization or even restrict the introduction of anti-patterns in code that might cause security hazards

Continuous Improvement:

CI also means continuous improvement where every single observation/miss in a sprint needs to be worked upon into an actionable item and incorporated into the cycle. Albeit there will always be unprecedented things, enough time should be spent looking back at how things could have been done — be it missed tests that led to production bugs or general processes that make life easier for everyone in the team.

Effective logging:

Probably one of the most underrated and least talked about points in CI, appropriate and meaningful logging can save days’ worth of effort in digging code trying to find the root cause. Both the service code and test code should have these loggings to help pinpoint right at the heart of the issue. We all know and have gone through the pain of setting up services locally, changing context between feature branches and spending hours on code written last week or even last month.

Team awareness: 

Everyone in the team should be hands-on with the CI pipeline. In teams, where the boundaries of roles and responsibilities are blurred, pipelines and CI jobs cannot be set up, operated and maintained entirely by a fixed set of people. Keeping aside organisations that have dedicated platform engineers, anyone must be able to do preliminary debugging, read test reports and communicate problems in the pipeline.