DevOps is very tough

DevOps - we all want the same thing!

DevOps, a new buzzword that concerns many companies. Many think: “Something new again! First agile, then continuous integration, followed by continuous delivery, and now DevOps ”. I can fully understand that in the flood of buzzwords that pop up each year, a certain amount of fatigue takes place. This blog post should help to shed light on the topic from the point of view of the project management - realistically and honestly. However, I have to warn you in advance: If you are looking for technical depth in this article, you will look in vain.

The term DevOps is made up of the terms development and operations, supported by automated quality assurance processes. As simple as that. But why were these two terms merged into one? Doesn't everyone already have enough work and tasks that need to be done? The answer, as is so often the case, is yes and no. Perhaps a practical example will help to untangle the confusion of my ambiguous statement.

Old patterns

As a project manager - especially as an IT project manager - you have to decide at the very beginning of the project which resources should be used. It quickly becomes clear that a wide variety of roles are required in a development project to make it across the finish line. We set up our project with the premise of meeting the requirements of the project client and the stakeholders, i.e. the magic triangle. Who should be on the core team now? So let's make a checklist:

  • Requirements manager (preferably directly from the department)
  • Solution architect (preferably someone who knows all the systems involved)
  • Developers (of course, we need exactly those who already know systems)
  • Tester (because of the complexity and the focus on quality, tests must be carried out manually as well as automatically)

Very good. So then we would have almost all of them. Wait a minute, there is still someone missing: the company or with the help of an Anglicism:

Operations!

Of course - somebody has to get the thing working and keep it alive. But they have to be part of the core team right away. No right? You put the high-quality, tested and approved software into production, so why bother you now?

And that is exactly where the mistake of reasoning lies. In my projects, I insist that the company is on board from the start. Unfortunately, this is often not the case, and towards the end many projects wonder why “the communication doesn't work”. So far, I've had very good experiences with getting involved at an early stage. Of course, the company does not have to be present at every appointment, just like the developers or testers or, subsequently, requirements management. What I mean by that: just because the company takes the software live according to the old thought patterns and looks after it afterwards, it doesn't mean that you have to constantly sit in all meetings. This also applies to all other departments involved in the project.

What exactly does this have to do with DevOps you ask yourself? DevOps goes one step further. In the course of my projects it was mostly the case that the IT project manager intercepts the operational side with the assigned software architect. The project manager on the organizational and scheduling level, and the architect on the technical level. So they form an interface between development and operation. As soon as questions arise, the developers turn to these people and not directly to the company. The middleman then turns to Operation. If errors are found in a deployment, it is returned immediately via the same route. As always.

 

There is another way!

The questions that now arise are: “Why is an interface required? Doesn't the company import the software from the developers? If errors occur, does the company have to carry out the analysis via log files and then play it back directly to the developers? Shouldn't development work more closely with the company on the basis of these points? ”You can see where it's going. This time the answer to all questions is quite simple: Yes, of course it would be important that the development department speaks directly to the company. But why should that change? My answer is already in the title of this blog article: we all want the same, efficient and effective approach. And let's be honest, false arrogance or top dog behavior has not yet achieved a project.

In my intro I wrote that the topic is described in a less technical way in this article. Nevertheless, I would like to refer to a few technical aspects. Many companies have recognized the potential for improvement mentioned above and tried to strengthen the cooperation between development and operation with various tools or toolchains. And guess what? It works! Let's take Continuous Integration and Delivery as an example. If this is lived, the software development gets a high degree of automation. The releases are getting shorter and more manageable, and consequently more manageable. This is reflected in improved time to market activities and the satisfaction of everyone involved. And by “everyone” I mean from employees to C-level. Sounds like a winn Situation, don't you think?

 

Ongoing activities

If the terms Continuous Integration and Continuous Delivery don't mean anything to you yet, I would deal with them a little superficially in this paragraph. If you can no longer hear these terms, please jump to the next paragraph.

To keep it short: The term Continuous Integration (CI) describes it quite well in itself, the implementation of a continuous integration. For this, many aids are used for efficient and comprehensible procedures. These are lightweight collaboration development tools, automated test processes, clean code versions and the resulting reports that make life easier for everything. Continuous Delivery (CD) is then an extended procedure based on CI, which simplifies the commissioning (deployments) of the software or parts of it. The packages are to a large extent imported into various systems and before that, often automatically regression-tested at night, so that no more production-endangered errors occur. As you can see, these processes already describe a high level of automation from which development, quality assurance and operations benefit.

In order to guarantee this, I would almost say "seamless" collaboration between development and operation is necessary. Without DevOps, CI and CD will remain relatively ineffective and unsuccessful.

 

Times are changing - the country needs new methods

"Why should the approaches without DevOps be unsuccessful? If the developers and the company each have their own tools, will it still be more efficient and the software will be handed over as usual? ”This is not entirely correct, as this principle only becomes effective if one proceeds according to agile principles.

Don't get me wrong, the article is not intended to degenerate into an ode to agility in software projects. However, it must be noted that the way software is conceived, developed and put into production has changed significantly. There are no more hard cuts, everything flows into one another. Now one or the other will say: "Yes, but we have been successfully doing classic software development with the waterfall model for decades: requirements, development, testing and then production setting". Subjectively, this may be true, but the fact is that projects will be delayed, cost more, or content will change. In the worst case, software is delivered that is no longer required on the market. One of the essential points is the constant search for errors or the amount of software that is constantly made available on the market. Today there are many vendors, endless substitute products and new ideas all the time that need to be implemented quickly in order to gain a foothold in the market. Everything moves faster and interest in software disappears faster than companies can react. If you stick to your old habits, you will even be overtaken in the right lane these days. So there are new ways to develop software. The time factor plays an increasingly important role. Or do you not want to be one of the first to bring a product and a new idea to the market in high quality? Now I hear a voice from the back rows: "Regardless of whether CI, CD, DevOps, ... There have always been mistakes and will continue to exist, so what does it all bring us here anyway?".

The answer is easy: with the DevOps approach we may have just as many errors, but we recognize them much earlier, fix them faster and more efficiently, and thus drastically reduce the overall lead time. In addition, tedious manual tests are almost completely automated. This in turn saves time. With the help of service virtualization, it is possible to simply map entire heterogeneous system landscapes in order to carry out tests quickly and close to production. Likewise, the topics of deployments, log files, voting on wrong versions, fallback scenarios or release notes become obsolete. This, as you already know, also saves time.

 

Close coordination and amalgamation of activities

To conclude the practical example from above. The company has to be on board from the very beginning and, according to the DevOps idea, be in constant coordination with development. There is a suitable toolchain for the company, e.g. in the JAVA environment IntelliJ (development environment) - Git (code versioning) - Maven - Jenkins (build server) - Cucumber (testing) - Puppet (reporting, control) or in the .NET environment of TFS. The combination options are very large these days, as is the range of tools available. And who says that the tools should only be used by the developers or the company. Here, too, the boundaries are no longer clear. Operators often program scripts in order to have automated routines carried out or test them themselves to ensure that the software runs correctly. The developers also deploy in test or integration days. So why not develop a strategy where the activities can be carried out by everyone to ensure that everything runs smoothly?

 

Sharpen the mindset: together we can move more!

So what else can go wrong? Unfortunately a lot. Not only mastering this toolchain is important, but also mutual understanding. It is an interpersonal matter, “thinking outside the box”. It can no longer say: “The developers have already delivered a faulty package” or “The lead time in operation is amazing”. Rather, it must be a togetherness and not an exchange of blows of accusations, regardless of whether they are false or justified. When it comes to the latter, you always have to keep in mind that there is always a reason why people react the way they react. A natural WE must be established, a team must emerge that no longer sees itself as separate from one another. Short: a DevOps team!

 

Conclusion: This path will not be an easy one ...

How do we get there now? The answer is not a blanket answer. DevOps has to be understood, established and lived. For this, as is so often the case, a consistent commitment on the part of management is necessary so that this change in the corporate landscape can also be carried. Management must live this mindset and actively support it. This entire process is a change, a change, and people react very differently to changes per se. That is why DevOps have to be created step by step. It is very important to keep the employees involved in mind with a goal that is being pursued. Your company will benefit from it. Stay tuned, bring people together, and discuss how they can become a DevOps organization. Believe me: the sometimes hard way will be worth it and your DevOps teams will bring high added value for the entire company.

I hope I was able to give you a little insight into the topic of DevOps. First of all, it is a mindset, joint action and mutual understanding, supported by a broad portfolio of really useful tools and toolchains. Find out what works best for you and define your DevOps as they see fit.