Autor: andreas.behrens@centa-gmbh.com

An effective DevOps organisation is only as good as the people in it. The composition of the team depends on the product under development, its maturity stage and the culture of the company. What works for Google, may not work for you.

Having said that, there are models from which to choose: each with its own advantages and disadvantages. The transition to DevOps will not occur the same way in different companies. How then do you create and effective SRE team and what common patterns are needed for it?

DevOps and Agile are about delivering business value faster and more reliably. The key driver for improving software pipelines, first and foremost, should be adding business value. Too often, however, the temptation is to focus first on tools and process second. The order should be reversed. First we decide what business requirements are most important, determine the processes that are best suited for the company to achieve those requirements and only then choose (or develop in house) tools that fit those requirements.

But, how can we align business needs with development decisions? This is challenging and it is often difficult to decide where to begin. A CTO, VP Enginineering or development lead will ask herself some fundamental questions:

“Do I want to improve my speed to market or do I want to create a DevOps organisation?”

“Can I do both at the same time?”

“Are my development costs too high or are my processes slowing me down?”

“How can I optimise my current setup without disrupting ongoing projects?”

Continuous Integration and Delivery is at the heart of the DevOps and Agile movements. CI/CD is software development discipline: releasing products in increments, where software can be released to production at any time. It is important to stress that the verb “can be” is not “should be” or even “is”. It is one of a number of possibilities provided by Continuous Delivery. Releases (which may be deployments to production or deployments to production-like environments, follow a “Low-Risk Release” principle, which means releasing should happen frequently (every commit) and with small change-sets. Continuous Delivery is a means by which a group or individual can make frequent product releases (deployments to production) but has the option to choose not to whether for business reasons or product constraints preferring a slower rate of release. Continuous Deployment takes continuous delivery to its logical conclusion and automatically deploys every change to production. That last step, however, is a business not technical decision and may not be appropriate for all products or services.