Voice of the DBA

One of the ideas behind DevOps is that we minimize the time between code commit and deployment to production. We want to avoid work-in-progress and bottlenecks to getting our software into the hands of customers. This has led a lot of companies to release more often, albeit with smaller sets of features. The total number of things delivered under DevOps might not be greater, but it often is more targeted to those things our customers want/need/use.

However, the idea of releasing often means that we try not to stack up too much work before deploying it. What does that mean for holidays and the code freezes or no-deploy periods that many companies have? How do you implement a code freeze under DevOps?

I read an interesting series on code freezes (partially paid content: part 1, part 2, part 3), and it looks at some of the implementations, data from surveys, and pros/cons of implementing a code freeze.

Two things here. First, I like code freezes as it gives staff a break. Two, doing this in a way that doesn’t just shift work (and stress) is hard. Do you have code freezes or deployment restrictions at your company? Do you like them?

The post has lots of metrics from various companies, some known, some anonymous. It seems that for those companies using code freezes, they help employees take a break, but not everyone takes a break, which means some work is done and merges after the code freeze are problematic. For those who don’t mandate a code freeze, less work is done when people are gone, but some work continues and is released.

I think the natural flow of work is that when fewer people are available, less work gets done. Poor management (or a hero complex) might overload the staff still working, but that doesn’t work long term. It might work now, given there is an oversupply of tech people and fewer jobs, but when things change, people will leave those positions, and lower quality, or at least less knowledgeable people, will cause problems for those firms.

I’m not a fan of code freezes, but I am a fan of understanding that staff needs a break. Lots of people want to take time off during holidays, especially those with children who want to celebrate or travel. Others might be fine working and want to catch up on work, refactor things, or maybe address tech debt. I’ve been in both situations, and I hope organizations can adapt to both situations, though without sacrificing quality. We still need good code review and testing, and if there isn’t the staff to do those things, then delay merging code.

The one thing that stood out to me was the learning that changing the pace is good for humans. If you’re in the habit of releasing every week (or day or whatever), moving to a different cadence for some time is good for you. Just as high-pressure work can’t be sustained for a long time, very slow periods aren’t good. However, both have their places as a change of pace. A high-pressure situation might be necessary to meet a business goal (or solve a problem). A low-pressure time might be a good time to think, experiment, and perhaps innovate.

Or just fix and refactor some poorly designed technical debt.

Do you want a time when you aren’t trying to get code to production, either as a dev or operations person? Or do you like to have your job predictable and work in the same pattern year-round? Let me know today.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.