After the astounding response to my previous article on DevOps, I am planning to continue this series and cover most of the topics related to DevOps. As mentioned in my previous article, DevOps started off as a system that integrated Development and Operations teams to collaboratively work on a software development project, it has greatly evolved now. Today, DevOps cross-functional teams include people from QA, security, administrators, data engineers, analytics engineers, and business management.

In this article, I am going to talk about most of the areas covered as part of the usual DevOps lifecycle.


I will start with the most common one since development is the key to everything here. DevOps came into existence to ease out the development and release process. It starts with building a brand new application. Currently, we don’t have anything and the team starts with the requirement gathering stage.

This is usually done by the project managers, architects, and pre-sales people. The application specifications, requirements, and design details are created. Architectural high-level documents (HLD) are created. It is quite rare that a developer has to join these initial calls since the architect is doing the actual prework. Once the client or end-user comes up with the requirements and comes up with some sort of plan or requirements for the Application. The team needs to start working on a brand-new application.

In regards to tooling at this stage, there is no real requirement here other than choosing your IDE and the programming language you wish to use to write your application.

As a DevOps engineer, remember you are probably not the one creating this plan or coding the application for the end-user, this will be a skilled developer.

But being able to read some of the code will definitely help you make the best infrastructure decisions moving forward for your application. And this will also help you when you would be debugging the releases and pipelines as part of the deployments. Not to mention, this should be maintained using a version control system, and the most common version control tool is Git. This helps track the changes, reverting the changes which caused the issues, and debugging much easier.

As part of version control, the best practice is to use a central code repository which allows collaboration easier and more productive. This could be a private or public code repository. As a best practice, it will be a private repository most of the time. And you might even host this in a local environment such as a local Gitlab server to ensure nothing is hosted outside your network. Check out my previous article that explains how to configure a private GitLab server. So you should be familiar with the terms such as Git, GitHub, GitLab, and Azure DevOps.


This is the point where all the requirements are clear and the development team has done their job of developing the application which is ready to move into the testing phase. Now the team has to start testing the application. And depending on the requirements or the application the type of testing will vary. But the most common testing that the team will perform is Unit Testing, Smoke Testing, and Regression Testing.

We can say this is the most important phase of the lifecycle that will ensure your application is ready to deliver what it is expected to deliver. This phase is also likely going to be automated as part of the next area which is Continuous Integration.


After the development and test cases are ready, the integration phase starts. This is where you start configuring the CI section of CI\CD. It is the practice in which developers commit changes to the source code using the version control mentioned in the development section above. This could be on a daily or weekly basis or depending on how the team has decided to plan the build.

With every commit, your application can go through the automated testing phases and this allows for early detection of issues or bugs before the next phase. This is often called the build phase\build pipeline, where your code is built to generate the artifacts. Artifact is basically a deployable component of your application that will be used in the deployment section.


So far you might have understood what goes in when planning the development and building the application. Now you have the artifacts ready to be deployed and consumed. This is also one of the phases where the operations team is engaged extensively. Because the operations team needs to ensure the deployment is successful and all the nitty-gritty of deployment is right.

This is the stage where the code is deployed to the servers. There will be different environments such as development, testing (QA), and production. And depending on the requirements you will configure your CD part of CI\CD. This is often called the release stage\release pipeline. Because different applications possibly require different hardware or configurations. This is where Application Configuration Management and Infrastructure as Code could play a key part in your DevOps lifecycle. It might be that your application is Containerised but also available to run on a virtual machine. This then also leads us onto platforms like Kubernetes which would be orchestrating those containers and making sure you have the desired state available to your end-users.


If you have been following this article so far successfully, congratulations you have an idea of what CI\CD actually means. Once you have your application deployed, you also want to continuously monitor the application. This will ensure you don’t face any unwanted surprises. Based on my experience things will keep moving and the team will keep pushing new changes and enhancements which is why we have to ensure our application is performing as expected. We also need to ensure our intended audience is getting the desired experience.

This is where different monitoring tools such as Grafana, Prometheus, and DataDog can help. This will help your team to make better decisions regarding sizing, application stack, or anything for that matter.

Monitoring is of no use if you don’t have actionable feedback which means you will also have continuous feedback involved as part of monitoring. Feedback will ensure you listen to your end-users and are providing the best user experience possible. Monitoring also helps you keep track of your expenses. If you are running your resources on the cloud, you want to keep a tab on the expenses that occurred, which will eventually help you plan\size your resources accordingly.


Reliability is a term that comes in handy when we talk about monitoring. Monitoring helps you observe the pattern and behavior. This will help you ensure your application doesn’t face any unwanted downtime and is able to meet desired service level agreement (SLA). Every business desires 100% SLA, but SLA and infrastructure expenses are directly proportionate. The higher the SLA, the more expensive it will be to ensure you meet the SLA or the uptime. This is also a role that’s more inclined toward site reliability engineer (SRE). But DevOps is the base of ensuring your site is reliable.


In conclusion, I will again reiterate the phase: DevOps is a mindset, that needs to be inculcated to ensure you meet the desired outcome. There are multiple stages and actionable items. But ensuring you have the correct approach and tools will ensure the application development process becomes agile, scalable, and affordable.