DevOps - 5 Principles
My last DevOps article was published 3 months ago, so I assume it is time for another one. The last time, we had a look at ideals – things you will never reach, but always aim for. Now, let's have a look at principles – things you can apply to work towards ideals.
My last DevOps article was published ~3 months ago, so I assume it is time for another one. The last time, we took a look at ideals – things you will never reach, but always aim for. Now, let's take a look at principles – things you can apply to work towards ideals.
Pre-face
After talking about different ways and types of work, but also looking at ideals, we will slowly move in the direction of "doing".
Similar to the Agile Manifesto or the content in the Scrum Guide, DevOps principles provide the proper framing for daily work, but also strategical decision-making. DevOps principles are work patterns, which can be applied to your daily work. One might also say, they provide the most demanding rules for a proper DevOps culture.
5 Principles
In general, the following 5 principles can be applied. I will explain each of them and how they affect your team work.
Collaboration
Collaboration is the key premise for DevOps. Even if you start with DevOps, you need to start here. The collaboration principle is applied to the work in a team, but also across teams and even towards customers and users.
Well, but how to collaborate more? The most common pattern is, that operations and development teams are merged. But there are so much more options and ways to improve collaboration.
- Do daily meetings
- Do public review meetings
- Educate other teams about your work
- Make your code public for the company
- Allow and foster merge requests to your code
- Open issues and merge requests for other teams
- Do proper user-, admin-, and developer-documentation
- Provide resources like showcase videos, blog articles, etc.
- Do interviews with your peers
- Use Conventional Commits
- Maintain a Changelog
In the end, the team should own the product from database to user interface, including the deployment and maybe even infrastructure and user support. To make this happen, you and your team must become cross-functional and fully aware about each and every facet of your users.
Automation
Automation of the software development cycle is another essential pattern, you can find in DevOps. This will give you more room to develop new code and provide innovative products to your users.
Every so often, people consider CI/CD as the only automation possible. This is true, to some degree, but there is so much more.
- Synchronize your work tracking and code tracking
- Automate recovery on issues
- Automate ticket creation from various sources (mail, chat, ...)
- Automate your quality measurements
- Automate the execution of tests
- Automate the creation and sending of release notes
- Automate the documentation publishing
- Close tickets on merge, link merge requests, ...
For me, automation is a method to create some time for me. But, it is also there to ensure processes are done right, tests are executed as designed or releases and deployments are reproducible. After all, the perfect workflow may look like:
# Start
$ git clone
$ git checkout -b mybranch
$ git push # automatically linked to your issue/story/ticket
# Do coding
$ git add .
$ git commit -m "Conventional Commit message"
$ git push # automatically updating your issue/story/ticket
# Open Merge requestIf you don't know where to start, make a flow diagram of your software development lifecycle from Planning to Release/Deploy and find all manual steps. Which of them are breaking frequently or cost a lot of time? Which of them are super risky or expensive? Start with small improvements there and work your way forward.
Continuous Improvement
Another, pretty important principle is continuous improvement. You might consider this as a "I need to learn new things"-pattern, but there is so much more to it. In DevOps, you can improve on a regular basis by:
- Knowing your metrics (DORA – I will write a blog about these, next)
- Doing retrospectives/postmortems
- Releasing more often and learn how to do it better
- Improving your software continuously
- Introducing new tools, but also get rid of old ones
- Gathering (actively) feedback about your product
In the end, you can improve each facet of your work. Sure, you need to work on real work, but dedicating some time to continuous improvement will keep you fast, innovative and increase your impact with your product.
Customer-centric action
DevOps teams will use short feedback loops with users and customers to develop products and services centered around user needs. In the past, I often heard statements like: "We don't know what our users need." or "I just want to make cool software." and "The customer ABC has opened 3 bugs again, what a pain."
DevOps works in the exact opposite way. You, and everybody in your team, need to learn that your users and customers are there to ask you for new features, raise bug reports and keep you busy. This does not mean, that you will follow them blindly. But, what happens if your customers are getting a bug fixed or a feature they want? Right, they will stick with you, recommend your work and interact more often with you.
You can foster a good customer connection by:
- Doing regular surveys
- Doing interviews with customers and end users
- Providing proper admin- and user-documentation
- Establishing a customer advisory board
- Communicate with the customers, based on their demand
- Making bug reports a priority
- Inviting customers to your reviews and adopt the reviews accordingly
- Providing proper release notes and news about your product
After all, just think about what you expect from a product you like very much. Is it really about the features, only? Or is it about communication, marketing, ease-of-use, fast bug fixes, long maintenance cycles?
Create with the end in mind
This is a tough one, but really important. Just "coding something", is not an option to make your software product successful. You need to solve problems, create value and have a goal in mind how you can do this.
Very regularly, I am looking at so-called agile teams, that tinker their way forward, without having a specific goal or problem to solve. You really need to know what you are working on and how it should look like in the future. There are many options to do this.
- Write down your customer vision in 6,12,24 months
- Do pre-mortems/futurespectives
- Come up with a strategy for the next 3 months and stick to it
- Start doing solution designs before implementing
- Write down your wishes, the customer demand and stakeholder desires
- Give your team a proper name and slogan, like
"Flying Saucers – We make the best tomato sauce in the universe." - Measure your success on a regular basis
- Get rid of stuff that does not fit your goal
After all, you want to provide a product that should solve a problem for some time. Finding this concern, a solution to address it, and measurements to make it happen can be really exciting.
Docs & Links
I also want to share some additional resources about DevOps principles.
Atlassian
Conclusion
Well, I hope this helps to shed some light on DevOps and how you can start with it. Are you already doing some above-mentioned methods, meetings, and tooling? If so, I would love to hear how it works for you. I would also like to get more ideas and how you apply the DevOps principles in your team/company/project.
