Faster is always better if we’re talking tech. Right?
Most dev teams outside of the Fortune 1000 landscape feel, at least at some point, that they would kill for the resources to shorten their development and release cycles. Management is grilling them from one direction; customers from the other. In practice, however, optimizing development and release to the exclusion of other improvements often gives us the “dog actually caught the car” scenario. They don’t know what to do with it once it finally happens.
Continuous integration and delivery pipelines have now allowed savvy dev teams to focus specifically on shortening the app release cycle. Automating each build and test while improving code in real time is certainly a boon for development and deployment. When the two processes of building and testing are managed through the proper tools – Azure Pipelines, Jenkins, TravisCI, et al. – delivering apps becomes a much easier process. When properly timed with end user expectations, the result can be higher rates of customer satisfaction and a more efficient (and well respected) DevOps department.
When DevOps go faster, the entire business benefits. Better time to market means that applications have more time to provide value to the market. Usability improvements come more quickly, and they are more significant when they come. The workforce is also happier, because their improvements are better received with more time to deal with any mistakes that occur in the process.
The cost of speed is maturity. Even with the ability to make changes in the testing environment in real time, continuous deployment may not be the right path for every company bar none. This type of deployment can actually negatively affect mission critical workflows if they are too fast.
Super fast cycle times may also limit the size of the team that you can manage. The lower that your cycle time goes, the more efficient your communications need to be. Getting that kind of cross functionality in some situations becomes impossible. If the development of a large app requires too many technical specialties, you’d better hope that you don’t get more than one type of error at once. Manual regression testing also becomes next to impossible – automated testing becomes the beginning and end of the process.
How good are your Dev and Ops teams at working together without the oversight of the executive wing? Do you have any egos or process hiccups that you haven’t been able to shore up with your slow dev cycle? These problems will only get worse if you try to speed up the process without taking care of the internal issues first. You also need to optimize all aspects of your software development in a fairly steady fashion in order for superfast dev and release cycles to work. It takes an incredibly confident company to release production changes in under an hour like the dev cycle industry pacecars.
It is certainly advantageous to have the means to drive a shorter dev/deploy cycle. Does it always need to be implemented? No. The best compromise is to optimize instead of glamorize – no one is going to benefit from a hasty release date pushed up to keep up with the Joneses. At the same time, all of the wolves at the gate must be admonished not to scapegoat the DevOps department, especially when the performance/process bottleneck may actually lie at their own feet!