Minimum setup for efficient DevOps
All organizations want to do “DevOps”.
This means a lot of different things to a lot of different people, but in general, they want to improve their software development life cycle (SDLC). In a nutshell, from the business point of view, they want new features and fixes to be developed and released faster, with fewer release problems, with little or no downtime. The current best method to achieving this, is the “DevOps” setup and culture.
The advice here is not for new companies/system that have the luxury of using all the latest and greatest of everything. This article is for the many companies with “legacy” code, especially smaller enterprises, that are used to doing a lot of things the old-school way — division of responsibility, semi-automated releases, QA, approvals, sign-offs etc.
Who is this advice for
This series of articles will outline a shortest, minimum resistance path towards a well functioning DevOps culture that will allow you to achieve very aggressive time-to-market targets, with reliable frequent releases with short downtime.
Who this advice is not for
This is not a recipe for a modern DevOps setup for new products. The web is full of such advice. This guide focuses on the minimal set of changes a typical mature organization needs to take, to improve their time-to-market and reliability. I will illustrate how you can take a traditional setup, and transform it to a modern setup that you can be proud of.
What you can expect to achieve
If you have monthly or longer release cycles, you can get it down to a weekly cycle. If you have an hour or more downtime, you can get it down to minutes. If your customers are used to find bugs after a release, you will not only have fewer bugs but you will be able to internally spot the few that do slip through. If you find your self doing “patched” of important fixes or changes, that is different then the regular release process, you will be able to eliminate that completely.
What will it take
Minimum effort does not mean it will be easy. You will need initial buy-in from tech leaders and up. The changes will be so positive, that you will be able to easily win over the rest of the team. The transition can take anywhere from 4–12 months to accomplish. I suggest you do not hurry and take your time. Change is difficult; give people the time to adopt. This will make everyone happy and increase the chance of success.
What to start with
If you have many systems in your organization, start with the most often changed system first. You need to get good at using the process, and this has to be practiced. Pick a system that could have weekly release schedule. A system that requires a change once a month, may not be a good candidate — not enough chances to test the process well. If you have a choice, pick first as system with as few database schema changes as possible. Reason for this will become apparent in later parts of the series.
Let the journey begin
You will need these, in the following order
- A proper use of source control
- A proper set of pre-prod environments
- A proper QA process
- A proper ticket/story/work item workflow
- A method to handle data changes
- A DevOps tool and DevOps expertise
- APM and Error tracking
