Companies from fresh start-ups to Fortune 100 and any other size in between, companies with any type of software product and service portfolios have already proven that: With DevOps your independent, small and self-sufficient teams deliver tens of production deployments each and every day. You design, build, deliver and test on production-like environments. You no longer release your code to your production systems in every third month after midnight while everyone else is sleeping. You release your code many times every day, and most importantly during your typical working hours, while your clients and market you are serving for still enjoy and get the benefits from your software.
DevOps does not only enable you to frequently deliver tiny software features, but also with the help from DevOps Dark Launch techniques you can frequently deliver small pieces of high-volume giant software features to your production. These small pieces wait in dormant (inactive) mode in your production until you switch the giant feature on from a configuration setting. Even only this one small technique can significantly improve the life quality of your team by avoiding big bang code roll-outs and their unpredictable adverse effects in your existing production systems, chaos and finger-pointing in your organization.
To serve your market, as you and your organization have a bigger mission than your competitors do, you organize your IT department with long-term teams around your client-serving (either internal or external clients) products, services, capabilities and micro-services. Instead of temporary project teams which dissolve as soon as or even before projects are done.
With the model of temporary project teams, individual project members neither have proper ownership of their own contributions because they rarely know where their project stands in the big mission of their organization nor they properly receive feedback about their work. Their work is constantly pushed to them in their area of expertise (database developer, front-end designer, translator, etc.) from various different projects, and they live in a world of continuous interruptions.
With the model of long-term teams, your teams willingly have the ownership of their work, IT and business performance enabled by their throughput. They are totally aware where their contributions stand and how important they are in the big mission of their organization.
You and your teams are fully aware that you are getting paid to serve your clients and to accomplish the mission of your organization. Therefore, you are respectful to everyone’s time and resources from your organization and clients. Before you commit any long-term project, you test drive and validate proposed and envisioned business value you expect from your IT solution. You show your clients the models, prototypes, various A/B variations or lightweight versions of what you intend to build. Then you measure and record their reactions and feedback to understand how you fine-tune your product and service, and if your clients like it at all.
You don’t add features to your product just because you have a good feeling about them. You test your ideas and build tangible, demonstrable and reproducible evidence that what you are building and investing the resources from your organization will most probably add the bottomline and positively differentiate your employer from its competitors.
You build fast, reliable and amplified feedback loops in all stages of your software delivery and operations lifecycle. Because quality is not a monopoly which belongs to a certain team, everyone strives for built-in quality. In order to make sure you have correctly done your job, you don’t wait for feedback from another team. Or you don’t ask somebody else’s permission to deploy your code in production. You trust your team with peer reviews of your design, code, test and infrastructure.
You always build test automation and monitoring (telemetry) for every possibly measurable and testable feature. You are conscious that if a feature deserves your time to be coded and delivered, it also deserves continuous, reliable, fast and consistent testing with test automation. Moreover, it also deserves continuous monitoring and built-in analytics in your software to validate what you win from this feature matches why you built it in the first place. In all environments including production and non-production.
Every check-in in your code repository automatically adapts, restructures or if necessary rebuilds your operational environments, automatically rebuilds impacted applications and ultimately executes all automated tests to validate existing features and the purpose of your latest check-in. Once validation is successful, the same changes are automatically adapted to your production.
Your built-in analytics and telemetry in your applications continuously monitor and record key events in your software and in its operational environments. The key metrics (such as number of orders, number of log-ins, CPU usage, RAM usage, CPU load, number of errors, length of database queries and many others) are continuously recorded and presented in real-time, so it is a matter of minutes, if not seconds before your team discovers a negative impact triggered by a deployment. This is why fast feedback loops are vital to get your job done fast.
If an error occurs, you solve it calm and confidently. You identify root cause of an incident by relying on scientific evidence obtained and observed from your automated tests and telemetry. If you identify a missing test case or missing telemetry after the resolution of the issue, you add them to your code repository together with your fix.
In a complex system like yours, no single person can know and foresee everything. Therefore, everyone in your organization believe that errors are not bad surprises, but they are part of maturity process of your products and services. Errors are opportunities to learn and grow. You and your organization conceive errors as a mean of new personal and organizational learnings.
Blameless post-mortems of errors will also enable you to even better identify root causes of incidents and discover techniques to avoid same and similar errors in the future. Thanks to your incident, you now convert your local learnings from your team and software into organizational memory which will serve everyone in your organization.
You and your team are never punished because of this error, but you are awarded due to the lessons you learnt and shared after this incident. Thanks to your contribution, many teams in your organization know how to avoid such an incident in the future.
Now imagine an average organization which evolves from 1 to 1,000 developers. As the organization was small, developers were continuously building and deploying their code to production. However, as the organization gets bigger, there is now a much larger organizational and bureaucratic hierarchy, more fear from mistakes. There is now more coordination and communication effort required to deploy your code in production. Therefore, average number of code deployments per day per developer usually reduces and at best remains same while organizations grow.
However, DevOps high performers play in a different league and they manage to increase average number of code deployments per day per developer as they have more developers. With correct software architecture, correct teams, correct mission, correct leadership and correct culture, DevOps high performers such as Google, Amazon, Facebook, Netflix and Apple have already proven that this is possible. Your organization can be the next one to become one of these DevOps High Performers.
High Performer DevOps organizations outcompete their rivals in following dimensions.