DevOps by Example: Tools, Pros and Cons of a DevOps Culture

There's a number of steps between applications and websites being conceived and being finally released --- design, programming, QA, and deployment. Let’s close the gap between the development and operations cycle, and review some of the practices of the DevOps movement.

Conventional Software Development: Dev vs Ops

Traditionally, there are distinct teams and processes for the different states of a project, from the initial states of analysis and design (when a product or idea is conceived), to the actual development and testing (e.g. when code is being written or a product is being developed), to finally deployment and maintenance (e.g. when a website, application, or product goes live).

There's good reason for this differentiation: they all demand a different set of skills. However, a strict (and at times even bureaucratic) separation of duties can add a lot of unnecessary delays, and experience proves that blurring some of these lines can be advantageous for all of the parties involved, and for the process as a whole.

This is true not only for software development, but for many industries. Think of Toyota, for example, the Japanese car manufacturer that's had, for many years, a strong culture of reducing what they call "waste" from the production chain so that they could fasten the flow of changes from development into operations. Furthermore, Toyota's practices have, in fact, heavily influenced the IT industry both in software development (see "lean software development") and in DevOps (see "Kanban: from Toyota to DevOps?" and "Using the Toyota Production System to explain DevOps").

DevOps: A Cultural Change for the Win

DevOps as the intersection of development, operations and quality assurance. Wikipedia.

Much like with agile development, DevOps isn't a particular tool or technique that you can implement and you're done. Rather, it's a culture ---even a mindset --- that your team and organization can adopt and that will make processes smoother.

But what is it exactly? Think of developers being able to do some of the tasks that are normally assigned to system administrators, such as creating new servers, making updates to production sites, deploying apps. Also think of sysadmins sharing some duties with developers, and being able to manage multiple servers at once.

Benefits

Companies embracing a DevOps culture report significant improvements, and different surveys conducted among some of them seem to confirm these claims (see "Continuous Delivery: Huge Benefits, but Challenges Too").

Some of the these improvements include:

• Accelerated time-to-market: shorten the time it takes from when an idea is conceived until it's available for sale or in production.
• Building the right product: developers get faster feedback from users with more frequent releases and live testing of ideas (more on this later on the "A/B Testing" section).
• Cost reduction: reports average a 20% reduction.
• Improved productivity: with continuous delivery, developers and testers save time setting up and fixing their working environments. Also, deployments are significantly faster (more on this later in the "Continuous Integration with Jenkins" section).
• Reliable releases: with smaller and more frequent releases, the changes in code --- and therefore the bugs introduced and their impact --- are also smaller.
• Improved product quality: companies report a very significant reduction in open bugs and other issues (in some cases, by more than 90%).
• Improved customer satisfaction: this is, not surprisingly, a byproduct of all of the previous improvements.

Examples

Same Production and Development Environments with Docker

The conventional wisdom goes that one shouldn't mix production with development environments --- that these two should be carefully separated in order to avoid disasters. And while it's true that making changes to a live platform without testing and rollback mechanisms is, in fact, a formula for disaster, having multiple environments comes at a high operational cost.

Automating the creation of environments is key in DevOps, and one technology that enables this is Docker. We won't get into the full details here, but the principle is that, with Docker, you can create a well-tested and functional environment (called an image) that developers and engineers in the operations side will be to launch as software containers. Whenever an update or patch is required, the QA team will just patch the image, and the changes will be replicated in every new container that's launched.

This gives independence to programmers and designers to launch environments that are constantly updated and known to work (and as many of them as they need), and even deploy changes to live platforms, because the QA people are maintaining these environments and have already set the appropriate tests. It also provides a communication channel with the server administrators, because they're all basically working together in having a working environment that's good for both production and development.

Notice that this is also valid if development and deployment are carried out by the same people --- as in a single freelance developer --- because these concerns for testing and implementing a live application in different environments are still valid regardless of who's in charge of doing it.

For more info about what you can do with Docker, see Understanding Docker, Containers and Safer Software Delivery.

Continue reading %DevOps by Example: Tools, Pros and Cons of a DevOps Culture%

by Lucero del Alba via SitePoint