DevOps isn't really about the fastest release process. Ultimately, DevOps should make the user's life better. Find a balance between velocity and utility.
We often talk about how DevOps and automation can help speed up release cycles and get the latest code changes and updates out in a quick, stable and efficient way. This DevOps mindset keeps developers and operations teams in sync and ensures that the software they produce is always on the cutting edge. But is this all too much?
With a continual focus on trimming the release cycle time and automating this process, do DevOps organizations put enough focus on the application itself? The DevOps mindset has fostered a more aggressive schedule of change. Is it always for the right reason? While this level of agility and change is often shown as a positive aspect for business, any change -- large or small -- affects customers.
When you make a change to your application, the customer may need to internally test and validate the app before it's deployed into production. In fact, that is normally the case with production-level software. If the application in question is updated monthly or quarterly, that can be a serious drain on your customers' resources for these internal processes. This is a piece of the puzzle can get missed in the DevOps mindset.
Orient your DevOps mindset around the user
When you practice high-velocity CI/CD, it's your customer who must manage these constant changes. If your DevOps team is making frequent, minor changes for low effect, is it really fair to expect your customers to continually update their own software?
Change for the sake of change costs the customer time and resources even with automation and quick lifecycles. Those benefit the release process, but not necessarily the customer adoption processes.
This doesn't mean that software deployments should go back to the monolithic approach. That simply wasn't fast, stable or efficient enough, but DevOps organizations have to control and communicate this change aspect to their customers so they understand what the change cycle will look like. And if you don't have a defined release cycle, or if it's random or based on when updates are ready, that's a huge red flag.
Communicate software changes
Change for the sake of change costs the customer time and resources even with automation and quick lifecycles.
Remember that companies rely on published software in production. That software has to work, so your customers will have controls and policies in place for updates. The argument that minor changes won't cause issues always seems to come up, and it only takes a few internet searches to find a lot of examples of minor issues that caused massive outages. So, while it's rare, it does happen, and DevOps organizations need to account for how a change could impact their customers.
This is why it's so important for a DevOps organization to look at any application update schedule and communicate it clearly to its users so they can depend on it and understand the benefits and risks of these updates. That takes time and effort, and it simply can't be done if your updates are coming too quickly. Find a balance.
This is where the balance aspect comes into play. A DevOps mindset needs to always have a customer aspect. DevOps can't just be about the release process and automation. After all, DevOps is supposed to be about the benefit to the user. You might have to slow down, but that's not a bad thing. Your code and applications should be focused on the customer. If you lose sight of that, who will be left to install all of your new application updates?
