TestVagrant

Contact Us

Essential insights for setting up your CI: What you should know

  • Blog

Blog

How to build a Real-time Test Case Monitoring solution using logs?

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.

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.

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.

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.

Space for everyone:

In a utopian world, all engineers in the team can dev-test, write automation, run regression and plan product demos in the same environment — but obviously it does not work like that. The ability to spin up and down environments at will for specific needs is the key. Oftentimes, we end up working on different builds of the same microservice and it becomes a nightmare to move things forward.

Apart from the above, there is one more category of tests that often people take less heed to or just act more reactively — performance tests. I believe a separate CI job can exist that includes spinning up a production-grade stack and running iterations on the most traffic-intensive dataflow paths. This can stay dormant and can be used only when any such releases are undertaken — for example integrating a 3rd party API or modifying cache designs for a service. Completely optional but a handy tool in your repertoire, for teams who are ready to invest in infrastructure costs and bandwidth.

While most of these should apply to teams working in agile, micro-service-based development environments, they aren’t set in stone. However, these guidelines might help you find the right direction towards striking that right balance for your team, churning out quality products day in, and day out.

Share This Article

Other Related Articles

See More Articles
See More Articles
Scroll to Top