Adopting a DevOps way of managing releases can reduce risk and improve your applications’ reliability. But, first, you need to make sure that you’re building applications in a way that makes sense for a DevOps environment.
Moving to a DevOps environment means that you develop an automated pipeline that allows you to reliably configure and then release enhancements to applications every day (if you wanted to — you don’t have to release every day if you don’t want to). That “reliably” is a very big deal because it requires you to manage not only your applications but the environments those applications operate in: the data stores, the routers, and the servers that make up the operational side of DevOps are just the most obvious examples . Those examples may not be the most critical parts of the DevOps process, though.
Often a DevOps initiative focuses on managing the configuration and release process for new software changes. Focusing on that aspect emphasizes the second part of DevOps — the “Ops” or operational side of things. But the first part of DevOps is “Dev” — the developer side of the process. I don’t think that relationship is accidental, because it’s the Dev side that allows you to control the risks of moving to a DevOps way of life.
Improving the process for delivering software enhancements can not be traded off against increased risk. In fact, the DevOps process is designed to create a process that not only speeds delivery but also reduces risk –many parts of the DevOps toolkit are designed specifically to reduce risks.
One critical part of reducing risk is a best practice: Test Driven Development (TDD). TDD (or automated testing in general) is designed to ensure that changes to the software environment all work, all work together, and haven’t broken anything that worked in the past. That goal won’t be achieved unless developers test their software as they develop it and have those tests automatically repeated as part of the deployment process.
However, the reduction in risk that tests provide is just the obvious output of TDD. TDD also encourages developers to work in small increments, writing just enough code to pass one more, precisely focused test. Developing in small increments also reduces risk by reducing the amount of change that takes place. This ensures that, if anything does go wrong, you have a small number of places to look in to find the problem.
Unfortunately, it’s only possible for developers to work in small increments if the software is designed to be enhanced or changed in small increments. For TDD and DevOps to succeed, therefore, it’s essential that it’s possible to extend or change an application by working on a part of the application, rather than having to work on the whole application. Applications must be developed as a set of components that can be worked on independently of each other and then integrated back into the whole application.
This is where design patterns kick in: The point of virtually all design patterns is to define the software components that address specific application needs. Those components can be worked on, tested, and checked in independently of each other. In addition, design patterns also help ensure that adding new functionality is done by writing new code, rather than modifying existing working code which reduces risk to the existing code base. Design patterns, like TDD, are essential to DevOps success and contribute to creating risk-free deployments (or, at any rate, risk-less deployments).
However, if you’ve noticed that design patterns and the best practices have been around long before DevOps appeared, you’re right. Even if you’re not thinking about moving to a DevOps environment, the benefits of the best practices and the design patterns pay off for you in reduced costs, higher productivity, and more flexible applications. But, if you’re thinking about moving to a DevOps environment, these practices stop becoming “nice to haves” and become essential.
If you want to learn what matters in implementing DevOps — or just find out, in depth, what DevOps is — then you can, of course, take Learning Tree’s Fundamentals of DevOps course. Before you do take that step, however, you need to make sure that you’re building applications in a way that makes sense in a DevOps environment. Specifically, you need to make sure that your applications are built are using the practices described in Learning Tree’s Java Best Practices and Design Patterns and .NET Best Practices and Design Patterns courses.
As those course names imply, they both have two parts:
The two parts are interrelated (using design patterns is a best practice, for example). What many people don’t realize is that both parts are not only going to make you a better developer right now, they’re essential if your organization wants to move to a DevOps environment.