We recently started a new project with a client who already has a DevOps mindset. It’s very refreshing to work with a team that values DevOps principles and appreciates the cultural changes that need to occur to deliver high-quality software frequently and consistently.
We were pleasantly surprised when they mentioned that they value:
- Production-first mindset
- Small batches of work
“Done” means in Production
That’s right. A user story is not considered “done” until it’s in production. Often times, teams without a production-first mindset, “done” means deploying to QA or a QA person validating a story in this environment. Teams are then encouraged to work as “feature factories” and keep improving on Agility on code that doesn’t actually make it to production.
The clear implications of changing the definition of “done” to production are:
- Committing to less story points each sprint
- Releasing often and in smaller batches
- Making the releases repetitive and boring
“You build it, you run it”
Some companies with a DevOps mindset like to encourage ownership on delivered work by having a “you break it you run it” attitude. Meaning emergencies that arise in production make it back to the originating team that wrote the code to address or help mitigate the issue. The idea with this approach is to encourage developers to start thinking about how features will be monitored, troubleshooted, and resolved when things go wrong much sooner in the process.
But I’m a developer and I really enjoy coding
Selfishly speaking, I’m a developer and I love writing code. The more time I spend coding, the happier I am and the better I get at my craft. So wouldn’t it be great if we had Waterfall again? No, it’s very unrealistic to expect a Waterfall approach in today’s fast paced world. The business craves agility and the business pays for engineers to create software.
What we’ve learned very quickly after always thinking about releasing to production, we’re motivated to streamline inefficiencies in the process so that we can increase velocity but more importantly spend more time coding.
Usually our clients have fancy tools and lack the #devops culture. So interesting working with a client with an awesome culture lacking the fancy tools.
— Facundo Gauna (@gaunacode) August 23, 2018
More deployments per Sprint? I want to code
Deploying more often can quickly be overwhelming when these deployments are not automated. Manual deployments might not take very much to someone who knows how to do the deployment, but what if that person is sick? Also, what if a deployment goes wrong? That causes unplanned work that eats into the time that could be been spent on developing.
Also, just because the deployment is automated, it might not be enough. What if my manager approves a deployment at 3 pm and I can’t start the script until the evening? It would be much nicer if approval processes were automated as well so that as soon as my manager approved a deployment, the deployment script would run and in the event of a failure the change would be automatically rolled back and I would be notified.
I want to spend less time manually regression testing an app
I can’t skip regression testing the app; otherwise, eventually I will get an urgent phone call that the app is broken. The more break-fix changes I’m working on, the less time I spend on code. At the same time, I don’t want to click through every single page of an app because I would also have less time coding.
Instead, I can choose to spend time on creating unit tests to ensure that I’m proactively building a test-suite that can automatically be run each time I want to deploy. More unit tests means more time coding in the future.
I want less sleepless nights
If “you build it you run it” attitude means I will get a phone call if something goes wrong, I want to spend less time digging through logs during an emergency. I don’t want to spend hours digging through log files at 3 am to find the root cause of an issue. Instead, I’m motivated to use a centralized logging infrastructure so that all my logs get funneled to one place and I can query my logs to find the root cause.
What if my app is under high-load because of a batch process that happens at midnight? Then I could also benefit from thinking about auto-scale rules earlier so services scale on their own while I’m having a good night sleep. On the flip side, I don’t want to be bothered whenever the company is reconciling cloud costs and I will proactively conserve compute spend by establish scale down rules.
I want to establish trust with other teams so that my changes go out into production
Often times, we find that one of the biggest blockers to releasing to production often is the extensive process that companies follow to provide peace of mind to security, operations, architecture, and networking teams. In addition, with a Scrum/Agile mentality, I want to improve on each Sprint completed. To do so, the story points I complete don’t matter unless it’s deployed to production. One way to help ease fear or apprehension is to increase visibility into exactly what lines of code changed and the environment settings should be. Having source control be the source of truth for infrastructure, application code, and environment settings helps other development teams understand what the ideal state of an app should be. Lastly, using Continuous Integration/Continuous Deployment practices keeps developers out of messing with environments and it can eventually make code deployments “boring.”
I want to spend less time in meetings
Understandably, many companies like to have code reviews before code makes it to production. So if my team is releasing X number of stories in a sprint to Production, then we that means I could potentially be part of X number of code review meetings before those stories make it to production. To avoid these meetings, my team and I could choose to use Git and pull-requests to have the same level of transparency and collaboration as code-reviews but without the physical meeting itself.
Having a DevOps mindset can seem foreign and theoretical, but putting restrictions in the process like changing the definition of “done” can help individuals change the way they approach work in order to meet the goals. Most people don’t like to put out fires in production, having meetings, and being fearful of taking time off.
At Nebbia, we help companies deliver more value by adopting Azure and implementing DevOps practices. Reach out to us so that we can help your company spend more time on innovation and less time on resolving issues.