DevOps - Lifecycle
When it comes to DevOps, most people think of cloud, containers, CI/CD and automation. Well, this is true to some degree, but these are only tools. One of the underlying fundamentals is a proper lifecycle.
When it comes to DevOps, most people think of cloud, containers, CI/CD and automation. Well, this is true to some degree, but these are only tools. One of the underlying fundamentals is a proper lifecycle.
Let's take a look at an example and investigate how a DevOps pipeline reflects the work that needs to be done.
DevOps
In the past, I have written a bunch of articles about DevOps, including an introduction, types of work, principles, and ideals. Please give them a read, if you need more context for the same.
Author
Lifecycle(?)
First, what is a software development lifecycle? Or, to make this a bit clearer: "What are lifecycle management methodologies and models?"
Methodologies
Well, such a methodology should describe how a software is developed, deployed, maintained and updated over the entire lifetime of the software. There are various approaches, each coming with its own ideas and terminologies.
Most popular are methods that are named Software development lifecycle (SDLC), Application lifecycle management (ALM), or System development lifecycle (also SDLC).
Alexandra Altvater
Models
Such a methodology can be tackled in different ways. You may have heard of Agile, Waterfall, or Iterative development models. In general, the chosen methodology does not force you to work in one or another model.
You can find more details about these models all over the internet.
Tom Nolle,
DevOps and SDLC
That leaves us with questions like: "How does DevOps tackle the software lifecycle?" and "Which model can I use?". Let's take a look at the DevOps Lifecycle, the different stages of it, and how it fits in the above-mentioned models.
Stages
Every process is made out of some stages. This can be as easy as "first this, second this, etc." or more event driven like "if this happens, do this". The DevOps lifecycle is described in 6-8 stages, depending on the author and details that want to be provided.
I am mostly sticking with the 8 stages, provided by GitLab. But you can also take a look at resources from Atlassian, or a simplified version by GitHub.
Each of the below stages must deliver an artifact. This ensures that the process stage was completed and provides a tangible result.
Plan
The planning stage is one of the most cumbersome and time-consuming. It combines basically every task from ideation, to vision, business modelling or design. Sometimes, this stage also includes other frameworks like requirements engineering, prototyping (mockups and alike), but also reviewing bug reports and results from the monitoring stage.
The resulting artifacts should always be some kind of user stories, tasks, increment description, feature declaration, specification, or similar. For me, all of these are called workable items.
Code
During the coding stage (sometimes development or implementation), you can think of your IDE or editor. The base for this work will be a workable item from the previous stage. It's basically all the things you are doing between a git pull and git push. In this stage, all the problem-solving skills and coding skills you can bring are needed.
As a resulting artifact, the coding should be done, including tests, documentation and other additions that might be useful. For me, this is often considered code. You might consider that linting and conventions scanning should be done here already, too.
Build
When our code is done, we want to build something useful out of it. This can be all kind of things, from compiling the code, to packaging it in a container or another format. This also includes downloading dependencies and basically bundles everything to make it usable.
I consider the resulting artifact of the build stage a testable package. A testable package might include compiler flags that are useful for debugging, additional tracing tools or other helpers to make testing more beneficial and verbose. Depending on your version scheme, you might already assign a pre-release version to it, so it can be tested easier.
Test
With the testable package, we can run some important functional tests, including integration testing. In the best case, the workable item included these tests scenarios already, and we can go on here. We also want to ensure that some security tests, performance profiling and other more "expensive" testing is done. This stage should include manual testing and product approval, too.
As the resulting artifacts, we want to have a test report and an approval for release.
Release
The release stage takes our test report, documentation, testable package and maybe more to build a release package. This can include a re-build of our software to remove debug flags and verbose logging.
Releasing something does not mean, that it goes live somewhere. It's more about having a proper versioned package, that is approved from all sides to be "fine for production". I call this package a release. But, I also refer to it as Christmas present.
(Deploy/Configure)
When our release is done, we want to continue with deployments. This is a tricky one. Deployments can come in a wide variety. We might have a multi-stage environment where a deployment will be done on development, then stage and then production. It might be, that we don't deploy ourselves, but customers and users are taking care of it.
In any case, we want to ensure that the release artifact is working. Therefore, I recommend having at least one instance of your own software running and using it. The artifact we have after deploying our software can be named a service or system.
GitLab includes the setup of cloud infrastructure and the configuration of the same in this stage, which seems like a viable approach, if your team (or you) is taking care of the same.
(Operate)
Operating is again a bit tricky. The service might be running now. But what happens if one crashes? Who is taking care of scaling? In the best case, we automate the same. But, if the customer is operating a software on his own, we might not have the opportunity to do this.
Therefore, you need to think about this stage, depending on your demand. Think about service level agreements, maintenance contracts and worst case scenarios. Make it part of your behavior.
An artifact for this stage may be something like an administration documentation, a troubleshooting guide or a support hotline.
Monitor
Monitoring is worth an article on its own. In the last meetup, I also talked about different monitoring approaches and how these impact our perception of the service. In any case, we want to know how our service is behaving, how it is consumed and what goes sideways.
You might think of monitoring solutions like Grafana or checkmk. Please also consider user surveys, bug reports, crash logs and other observations from production deployments.
The resulting artifact are insights from the real world. There is nothing more useful. These insights can be used to be fed into the Plan stage and repeat the cycle.
Gimmick
When starting a new project, I am often trying to fiddle out how the "perfect" pipeline might look like for a project. The below diagram is an example of such a thing.
I really recommend to make something similar, maybe way simpler. It helps to understand what you want to do and in which stage it is needed. It also helps to identify gaps easily and "cross out" what was done and is in place.
Docs & Links
This topic allows deep diving and there is lots of content available. Below, you can find some additional links for further investigation.
AuthorAlexandra AltvaterTom Nolle,Conclusion
After all, the DevOps Lifecycle is just a specialized variant of PDSA (plan, do study, act) for me. The value lies in the implementation of these stages and helps to streamline work. Just having the process as a poster on the wall does not help. You need to do real plans, tangible tests, meaningful releases and severe monitoring of the usage of your application to make the process really work. This often implies to forget some common practices, learn something new and start over, even if something seems to work "OK".
What I am super interested in are the following things: "Have you already implemented DevOps methodologies? What went well? What went wrong?"
Please feel free to get in touch, provide feedback or connect via Mastodon or LinkedIn.
