What is a desirable time-to-market for a product? Of course, there can be no blanket answer here. But in the morning at the coffee machine to have an idea and in the afternoon, the first customers use the feature – that would be innovative!
Time to market for new features
But how can such a short time-to-market be realized? How can an idea from the morning reach the first test customer in the afternoon? Or how can I close a bug in the production system, maybe even within a few minutes?
The prerequisite for this consists of three essential components:
- high automation
- Cross-functional teams and
- a philosophy of learning.
A fast rollout only works if as few manual interventions as possible are necessary.
Continuous Integration and Continuous Delivery
A first step in this direction is software development based on Continuous Integration (CI): the source code is checked in and automated, code metrics are determined to determine the quality, and automated unit tests are performed.
A second stage is the automatic rollout, ie Continuous Delivery (CD) . The built source code is thereby automatically brought to the target environments.
Automation of testing is the order of the day: manual integration tests by clicking on surfaces no longer work. The role of the classic tester shifts so more to the test software developer or test scripter.
Even for small projects, it is advisable to start directly with the test automation: on the one hand to avoid manual steps, on the other hand, small projects are often larger than expected – and the subsequent construction of a test automation can be expensive.
The CD pipeline can span multiple environments. After the codechecking and the successful build, the delivery takes place on a test environment. There, the CD pipeline then performs automated integration tests. If there are no problems, the rollout is performed directly on production – ideally without human interaction.
Concepts such as Canary Deployment help to make new code in production available to a small percentage of users. If the new feature works, it will gradually be made available to other users.
Cross-Functional Teams bring together colleagues working together on a thematic project. The team brings together all the roles needed for the project. Existing silos are broken up: the team of developers, the team of testers, the team of operations – all this no longer exists in cross-functional teams. Rather, small thematic teams emerge that can portray all these roles.
Business + Development + Operation = BizDevOps
A basic idea of DevOps is that developers ( Devs ) and factory employees ( Ops ) form a common team and thus be able to deal with the problems of the respective work area right from the beginning. For example. The company places high demands on the monitoring and logging of an application. In close coordination, these can be directly taken into account by the developers. Also, the operations specialists know the typical scaling issues that should impact the application architecture.
For technical decisions, the customer or Product Owner ( Biz ) brings their expertise to the team. Like to forget, but just as important, are testers and security experts.
This team now handles a thematic area completely self-sufficient. For example. It develops a decoupled microservice and is always able to roll out a new version, ensure testing and operation, and drive development based on customer needs.
Each employee in the team still has its core competence. It’s not about the developers taking over the business in the future. Even if the team structure automatically leads to a better understanding of the previously foreign task area. Rather, BizDevOps ensures that interdisciplinary collaboration and communication is improved.
This also brings with it a new freedom : the team can organize itself and choose the best way for implementation and operation.
At the same time, the responsibility is growing: the team is responsible for its service at the end of 2-end. Everyone is in demand, for example, if there are problems on the production environment. Again, there is a suitable DevOps principle: You build it, you run it.
Learn learn learn
Current forms of organization such as complicated processes or strict division of tasks often exist for fear of mistakes and lack of trust towards their own employees.
But: Only those who are not afraid to make mistakes, have the courage to try new things and address problems. Innovation needs the support of colleagues and the courage of each one to create something new.
Not for nothing is a DevOps principle also: Fail fast, learn fast .
Therefore, I plead for establishing an open culture of error: Mistakes may be made. It is important that they are communicated so that everyone can learn from them.
In addition to the mistakes of individuals, metrics need to be collected to measure the success of the team’s work: is the new code better than the old one? Do the new features make our customers more productive?
Faster time-to-market requires DevOps structures
Have an idea at the coffee machine in the morning and in the afternoon the first customers use the feature? For a team with freedom of action, which uses automated processes and is not afraid of mistakes, this is not a utopia.
In addition, if we deduce from the customer’s behavioral data how we can make his life easier, a truly innovative product with a short time-to-market results. Customers like to commit themselves to such a product – which really claims to be helping the user.
The three principles presented are a small part of the DevOps culture. For some years, these principles have not only changed the classic product development, but entire corporate structures and collaboration concepts. A good introduction the Arvato poster for DevOps.
This post is automatic translated from the german version: https://cloud-blog.arvato.com/time-to-market-devops/