{{announcement.body}}
{{announcement.title}}
Refcard #314

Design Patterns for Continuous Delivery

Restructuring DTAP for DevOps

This Refcard presents a guide on how to rethink software delivery methodologies for modern software development. It demonstrates how to reinject the business function of QA and take advantage of continuous releasing in order to lower the risk of releases, shorten development cycles, and help software support business.

3,612

Brought to you by

Vamp
Free .PDF for easy Reference

Written by

Olaf Molenveld CTO, Vamp.io
Joep Piscaer Tech Writer, VAMP.io
Refcard #314

Design Patterns for Continuous Delivery

Restructuring DTAP for DevOps

This Refcard presents a guide on how to rethink software delivery methodologies for modern software development. It demonstrates how to reinject the business function of QA and take advantage of continuous releasing in order to lower the risk of releases, shorten development cycles, and help software support business.

3,612
Free .PDF for easy Reference

Written by

Olaf Molenveld CTO, Vamp.io
Joep Piscaer Tech Writer, VAMP.io

Brought to you by

Vamp
Table of Contents

Introduction

Section 1

Introduction

Organizations are adopting microservices and DevOps to stay competitive and increase the speed of releasing new functionalities with improved scalability, quality, and (cost) efficiency.

Current processes, tooling (continuous integration/testing/packaging/deployment), and Development/Test/Acceptance/Production environments (DTAP) are typically designed for traditional codebases and applications, manual and time-consuming testing, separate organizational silos and handovers, and “big bang” deployments to production.

With the move to DevOps, these traditional environments, processes, and tools no longer serve in reducing risk in the software delivery lifecycle (SDLC.) Instead, they act as a block to the full potential of increased efficiency in software delivery.

Because of the DevOps mantra of “you build it, you run it,” development teams are allowed a lot of autonomy and control, and are expected to also handle quality assurance (QA) and releasing tasks. The reality is that these are specialized and complex tasks that need expertise and dedicated toolng provided to software delivery teams. In addition, business outcomes are ignored as they are hard to validate for development teams, and QA becomes mainly focused on technical aspects.

In this Refcard, we’re going to give you a guide on how you can rethink your software delivery methodologies for modern software development — one that reinjects the business function of QA and takes advantage of continuous releasing in order to lower the risk of releases, shorten development cycles, and help software support business.

You will learn:

  1. How testing is handled in continuous integration, delivery, and deployment
  2. The promise of these three “continuous practices”
  3. How continuous delivery falls short on these promises in practice
  4. How DTAP stands in the way of continuous delivery fulfilling its promise
  5. How to restructure DTAP for continuous releasing to gain the advantages of continuous delivery for software and business  

This is a preview of the Design Patterns for Continuous Delivery Refcard. To read the entire Refcard, please download the PDF from the link above.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}