Guest Post by

DevOps for faster Software Development and Deployment

DevOps is a concept you often hear about. But do you really know what it means? DevOps came into existence over the past few years alongside agile software development. Shorter and shorter market cycles for software products created demand for more efficiency in software development as well as for faster and more frequent deployment. This entry discusses the demands these conditions place on development and deployment teams and the value of DevOps.

Mit DevOps Software schneller entwickeln und in Betrieb nehmen

Automation and Monitoring in all Stages of Software Development

DevOps (Development and Operations) is a culture and set of software development practices that aim at combining software development (Dev) and software operations (Ops) and promote cooperation over these boundaries.

The primary characteristic of the DevOps movement is to promote automation and monitoring through all stages of development, from integration, to testing, releasing, deployment and infrastructure management. DevOps and Agile are complimentary, both aiming at shorter development cycles, more frequent deployment, and more reliable releases. All of this is to be finely attuned to business goals.

Der DevOps Lifecycle

The DevOps Lifecycle

The development team produces functioning software at the end of every sprint. The software often has to wait, however, until the release date specified by the company. The release date itself can be delayed again and again, if the operations team isn’t prepared for integration and deployment, or the company isn’t ready to go live with the new functionality. Shorter time-to-market, a primary benefit of Scrum, is thus often not fully realized.

In the first sprint the development team must be able to establish that the product is feasible and creates added value. In order to accomplish this, an operations environment and initial architecture are required where the goals of service-level agreements can be achieved. DevOps supports this process as well.

Together, instead of Separate

In DevOps, the development and operations departments are no longer considered to be separate. Instead, they work together closely as a team. This cooperation is sustained over the entire application lifecycle – from design, to development, and deployment – in order to create products with the greatest possible value and to be able to bring them into operation quickly and at any time.

Faster and more frequent deployment is realized through automatization, not only in development (Build, Test), but also in deployment. The goal is to automate as much as possible. This takes place in an agile environment according to agile values and principles (Scrum.de, 2015). This leads to shorter cycles and earlier feedback from users. This makes it possible to see whether stability and reliability are turning out as planned.

All the tools and automation measures in the world, however, remain useless if the development and operations teams have no interest in working together. DevOps doesn’t solve problems by implementing tools. The focus is on solving human problems and promoting cooperation across roles and functions.

DevOps is a culture, not roles or software

Introducing DevOps takes time. It’s about establishing a new culture oriented according to agile values and principles, as outlined in the Agile Manifesto, and further values, like transparency, openness and respect. Creating sustainable change in culture requires years, not just months.

Frequent Delivery and Higher Quality

DevOps can help a team in the following ways:

  • earlier indications whether a product is feasible
  • automatization not only in development (build, test), but also in deployment and in between
  • close teamwork between the development and operations teams
  • better and more rapid exchange of information between the development and operations teams
  • ‘inspect and adapt’ across the entire delivery workflow – including looking for chances to improve human relations and cooperation
  • members of the operations team think like developers and vice versa
  • shortening and expanding feedback loops so that necessary corrections can be carried out

There’s an immense increase in efficiency from traditional testing to continuous delivery and DevOps. But the point isn’t just efficiency, but rather to get the product to market faster. To be second on the market often means game over. The pressure to speed up increases every year.

DevOps also has a positive influence on teams. People who perhaps didn’t have the best opinion of each other begin to work more closely together and to see the value of other disciplines. Everyone can profit from everyone else’s knowledge and build a better product. Added value is delivered at higher quality and with less cost, which also ought to lower risks.

DevOps Doesn’t Have the Same Effectiveness Everywhere

DevOps is the right method for “pure software development”, for example mobile apps, PC user software or web apps. Market adaptability and short release cycles are relevant here. On the other hand, if you’re developing for larger ERP systems, insurance systems, or systems where software is a part of the product, as in machine tools, airplanes or automobiles, DevOps won’t be able to give its full value. A current example of this is software for the Boeing 737 Max 8. Such systems have release cycles that last several months, not just weeks or days. In these cases, expert knowledge, thorough tests, acceptance processes and detailed documentation are an absolute must. However, even here an improved working culture between development and operations teams would have many positive outcomes.

Read more from Roland Wanner at his blog: https://www.rolandwanner.ch/blog/

See how you can use objectiF RPM for continuous deployment of microservices in the cloud.

 

Roland Wanner is senior program office manager and textbook author. In the past thirty years, he has been a project manager, project controller and project portfolio manager in the bank and insurance area as well as industry. He is the author of various books about project risk management, project controlling and Scrum.

Tags:
EN Subscribe to our newsletter
0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *