DevOps: The what, the why and the how (2/3)

In the first part of this article series, we learned what DevOps encompasses and why it is useful. We also looked in to continuous testing which is a vital part in making good and sustainable software. In this article, we are going to be looking at the next steps and how they relate to continuous testing.

Continuous Integration

The way I see it, continuous integration (CI) and continuous testing go hand in hand. Continuous Integration involves merging code changes into a central repository where automated pipelines are run, primarily for (but not exclusively) building and testing. Setting up a CI pipeline is vital to streamlining the process of getting changes into the rest of a software codebase. This allows the codebase to always be in a working state with the latest changes integrated. To achieve this, CI platforms are used, such as GitHub or equivalent services provided by Microsoft, AWS and the like (honorable mention to GitLab, an open-source Git version control system with CI services). Essentially, CI handles merging changes to code and building through pipelines. And this is where continuous testing ties into CI. As a part of the pipeline, automated tests can be run, and these can be used to reject code changes when tests fail. This, of course, requires proper test cases to be written, but it can allow developers to rest assured that they have not inadvertently caused a regression. This allows software teams to move swiftly, as it will not be necessary, in many cases, to perform numerous tests for unrelated parts of the codebase given sufficient tests are in place.

Continuous Delivery / Deployment

Following these improvements, the next step in the DevOps cycle is continuous deployment/delivery (CD). CD is the second component of the commonly known acronym CI/CD. To avoid it having to be a manual process (remember the troubles the team over at TheyTube are facing), CD focuses on always having a release-ready build of the software ready for manual approval and automating the release process. I combined the principles into one because they are very closely related, but more pragmatically speaking, continuous delivery is the part focusing on always having a release-ready pending manual approval, and continuous deployment is the part that handles automating the release (or deployment) process.

Right, but how do we apply this to our problem case?

The cumbersome process of building and uploading the new build can be replaced by the CI/CD pipeline which automatically builds and uploads to the environment from which it can be deployed. Once that is accomplished, the build is still pending manual approval. This part should not be changed—there should always be manual approval before deploying a build to a production environment to reduce mistakes (we are, after all, humans). Once the green light is given, the build can be deployed. This should not require much effort, and, depending on the type and scale of the system, the correct strategy for replacing the current build should be used. I am vaguely mentioning different strategies because there are good strategies for releasing updates on systems which are currently in use without interrupting the user experience, but that is a subject for another day. Practically speaking, this can be achieved using a CI server and a container app hosting solution which can be accessed from the CI server to trigger the deployment of the new release. I reiterate, however, that getting very specific about how to implement such a solution is for another day, but more specifically, the next part of this article series.

Honorable mentions

As I already alluded to, I am not going to go into depth on all the principles of DevOps, and this is the part where I go over the other principles rather quickly.

Continuous feedback means collecting feedback from users and testers to make changes to the product. Not all feedback will be helpful; not all feedback will be useful. It is, however, important to collect the feedback and develop processes to sort, filter and make use of the precious nuggets of information. We all know how it is to be so involved in the making that we lose focus on the bigger picture or how it is actually being used. This is why paying attention to feedback is important.

Continuous monitoring is similar to continuous feedback in that we are paying attention to how software is being used, but this does not involve any additional actions by the users. Monitoring involves collecting analytics of how a product is being used, as well as finding issues as they appear, before users make them known through feedback channels (which are generally less efficient due to volume and required processes). Adequate logging and traceability through software will go a long way to finding the root cause of a problem or provide a path for optimization.

Continuous operations refers to the tasks required to keep software running: all the manual processes requiring humans which cannot be efficiently automated. These may often be quite minimal, but that is highly dependent on the specific product. It is important to integrate these processes into the rest of the DevOps cycle to maintain smooth running, and this can be done by nurturing the right culture among the team.

In the next part of this article series, I will look closely into continuous monitoring. Basing on a recent experience, I will go into problems that can arise when continuous monitoring practices are not used and ways to remediate the issues by using good DevOps practices.