Embracing DevOps Release Management E-Book

Joel Kruger

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 573

Veröffentlichungsjahr: 2024

Beschreibung

At the core of software development lies the imperative of swiftly and reliably releasing new features and updates, emphasizing the vital role of release management in the DevOps methodology. Discover how software development teams can elevate their processes by incorporating quality checks and shifting left, moving testing, automation, and QA procedures much earlier into the SDLC. However, release management is still tasked with application monitoring, overseeing infrastructure components, and managing change orders and schedules.
This book offers insights into the essence of DevOps Release Management, illuminating its nuances and providing basic strategies for its implementation. You’ll explore how CI/CD pipelines enforce good DevOps release management and master techniques to optimize them. You’ll also learn how to foster a culture of cross-functional product development that minimizes waste and maximizes value to the customer.
By the end of the book, you’ll have gained a comprehensive understanding of DevOps release management, its benefits, and practical implementation strategies. Equipped with this knowledge, you’ll be able to assess your own development processes and identify areas for improvement, ultimately leading to increased efficiency, collaboration, and value creation.

Leseprobe

Embracing DevOps Release Management

Strategies and tools to accelerate continuous delivery and ensure quality software deployment

Joel Kruger

Embracing DevOps Release Management

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Preet Ahuja

Publishing Product Manager: Vidhi Vashisth

Book Project Manager: Srinidhi Ram

Senior Editor: Adrija Mitra

Technical Editor: Irfa Ansari

Copy Editor: Safis Editing

Indexer: Subalakshmi Govindhan

Production Designer: Aparna Bhagat

DevRel Marketing Coordinator: Rohan Dobhal

Senior DevRel Marketing Executive: Linda Pearlson

First published: April 2024

Production reference: 1140324

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-83546-185-3

www.packtpub.com

To my mother, Mary, and the memory of my father, Jon, for their sacrifices and all of the love they’ve given me throughout my life. Thank you for instilling me with grit and the drive to succeed. To my mentor, Gary “Cecil” Rupp, for your enduring support. Thank you for showing me what it takes to differentiate myself as a thriving industry leader in massive IT enterprises.

– Joel Kruger

Foreword

Release management was, for me and many others, the entry point to DevOps—the intersection of software development and IT operations where the famed “wall of confusion” stands, a barrier to continuous flow, feedback, and experimentation. The conflict and friction that the DevOps movement emerged to resolve were particularly intense at that point in the SLDC because agile software development practices caused developers to increase the cadence of throwing release packages over that wall into the hands of ill-prepared infrastructure management folks.

DevOps may now, 15 years on, be considered mainstream, but plenty of organizations remain in the midst of adoption or stuttering in their implementations, struggling to reach higher levels of capability (as shown in the Puppet State of DevOps Report 2021). Continuous integration isn’t an emerging practice but is now well-established in many organizations, but not all. Multi-functional, cross-skilled teams and small batches of work are the norm for some, but plenty of siloed, waterfall-oriented setups remain. Positive DevOps cultural characteristics such as effective collaboration and psychological safety may well be widely understood, but are hardly commonplace.

Release management itself has evolved. Many elements are now highly automated and the improved governance that comes along with that is appreciated by many, along with the acceleration of time to value and the ability to scale to release and deploy much higher volumes of enhancements to the customer experience. The onward march of digitization has further driven the adoption of distributed environments that allow for faster build, test, and release cycles thanks to smaller components. DevOps has further changed the whole game—and heavily influences the best practice patterns.

When I first met Joel, several years ago, his passion for DevOps and deep technical understanding blew me away and I jumped at the opportunity to invite him to join the DevOps Institute’s ambassador program. He has shown himself to be a true pioneer and visionary in this field, with an inexhaustible thirst for knowledge, and a particular talent for real-world applications of principles and practices.

Throughout Embracing DevOps Release Management, Joel shares the cutting-edge approaches he has learned as a practitioner over many years. The book contains hands-on exercises for release management in cloud-native environments and tools for readers to self-assess their capabilities. Readers will learn how to create effective CI/CD pipelines and continuous optimization techniques that drive the emergence of a cross-functional product development culture. The result is the removal of waste, increased customer value, and improved organizational performance.

Helen Beal

Head of Ambassador Program

PeopleCert (DevOps Institute, ITIL, Prince2, LanguageCert)

Contributors

About the author

Joel Kruger is a senior DevOps professional and solutions architect with over 10 years of experience building CI/CD pipeline infrastructure in commercial and federal sectors. He is also an expert in employing container orchestration systems for automating computer application deployments at scale. He is a proponent of building reusable CI/CD pipeline configurations as downloadable and self-serve software factories.

Joel is a very hands-on and customer-service-oriented person who loves to solve a challenge. Technology excites him, from cloud computing to embedded Raspberry Pi projects. He loves being creative with tech and is not afraid to get some hot solder in his shoelaces.

Joel owns and operates his own corporation, dynamicVSM, as a freelance DevOps consultant and has experience architecting solutions that scale, reduce waste, and increase visibility. He works together with clients to help manage their value streams better.

I want to thank the people who have been close to me and supported me, especially God.

About the reviewers

Vikas Mendhe is an accomplished software development professional currently serving as a senior consultant at the Office of the Governor in Austin, Texas. With a rich background in software system engineering, his expertise extends across financial applications, data integration, transformation, cloud computing, and project management. Holding a PMP certification, he brings a wealth of knowledge to the field. Vikas is proud to have authored scholarly journal papers and is recognized as an IEEE senior member and a member of the British Computer Society. Additionally, he has been honored with the Indian Achievers Award for his contributions to the field.

My heartfelt appreciation goes out to all the trailblazers who contribute to making this field an exhilarating place to work every day. Your dedication and innovation are truly inspiring, and we are grateful for everything you do!

I would also like to express my deepest gratitude to my entire family for their unwavering support and understanding during my busy schedule. I am truly thankful for their enduring support.

Vladislav Bilay is a distinguished DevOps engineer and tech reviewer renowned for his expertise in architecting cloud-native IT solutions and enhancing software development methodologies. As a certified AWS solutions architect and Salesforce engineer, he brings extensive experience in designing and implementing robust CI/CD pipelines and managing Unix-based systems.

Beyond his professional engagements, Vladislav Bilay has made significant contributions to the tech community as an esteemed industry expert and judge for prestigious awards programs.

In addition, Vladislav Bilay is a writer, authoring insightful scholarly articles on cloud-native technologies, GitLab CI/CD, and Kubernetes.

It is with profound gratitude that I acknowledge the privilege of being able to contribute to the body of knowledge in this field. I am humbled by the opportunity to share insights and perspectives that may inspire and inform future generations of scholars, practitioners, and enthusiasts.

Viachaslau Matsukevich is an esteemed professional with over a decade of experience in DevOps and cloud solutions who has led significant projects for Fortune 500 and Global 2000 companies. His expertise, certified by Microsoft, Google, and the Linux Foundation, extends to writing insightful articles on cloud-native technologies and Kubernetes. As a technical reviewer, Viachaslau ensures quality in technology publications. He’s also recognized as an industry expert and judge in tech innovation events and hackathons. Passionate about education, he authors online courses and has founded a DevOps school. Viachaslau’s commitment as a DevOps Institute Ambassador highlights his dedication to the DevOps community.

My heartfelt thanks go to my family and parents for their enduring support and for instilling in me the values of resilience and learning. Special gratitude goes to my wife, whose patience and encouragement have been vital. I am deeply grateful for her belief in my goals, which has been a guiding force in both my life and career.

Table of Contents

Preface

Part 1: Understanding the Software Development Life Cycle and Its Design

1

Understanding the Software Development Life Cycle

Defining SDLC and looking at its seven phases

1. Planning and Analysis

2. Define Requirements

3. Design

4. Development

5. Testing

6. Deployment

7. Maintenance

Defining some commonly used terms

SDLC versus other life cycle management methodologies

Software development Life Cycle versus systems development life cycle

SDLC versus release management

SDLC versus ALM (application Life Cycle management)

SDLC versus PDLC (product development life cycle)

SDLC versus SRLC (software release life cycle)

Release management versus change management

Release management versus project management

Summary

Questions

2

A Brief Introduction to Release Management

What is release management, and how did it evolve?

Definitions

A brief history of release management

The evolution from software to release management

Dissecting the release management life cycle

Request

Plan

Design and Build

Testing

Deployment

Post-deployment

Summary

Questions

3

What Are the Various SDLC Release Management Models?

The ITIL model

ITIL 3

ITIL 4

The waterfall model

The iterative model

The V-model

The spiral model

The big bang model

The agile model

The DevOps model

Summary

Questions

Part 2: The Advantages of DevOps Release Management

4

What Problems Does DevOps Release Management Try to Solve?

Exploring automated testing, deployment, and change management

Automated testing

Automating deployment

Automating change management

Reducing potential risks and accelerating the release of software products

Streamlining the release process so that it becomes standardized

Improving metrics and KPIs for successful releases

Four critical DevOps metrics

Summary

Questions

5

Understanding What Makes DevOps Release Management Unique

DevOps is holistic

DevOps integrates CI/CD, QA, security, and feedback

DevOps incorporates business teams into the development process

The three ways of DevOps

The first way – flow/systems thinking

The second way – amplify feedback loops

The third way – a culture of continual experimentation and learning

How do traditional release management methodologies stack up against DevOps?

A case study of how DocuSign transitioned from Agile to DevOps

The genesis of DocuSign

The transformation to DevOps

Obstacles encountered by DocuSign’s product team

Summary

Questions

6

Understanding the Basics of CI/CD

The ABCs of CI/CD

What is a CI/CD pipeline?

What is continuous integration (CI)?

Selecting the right CI tool for your operations

What is continuous delivery (CD)?

What is infrastructure as code (IaC)?

The continuous delivery pipeline

The difference between continuous delivery and continuous deployment

How GitOps fits in with continuous delivery

What is continuous testing?

The DevOps transformation of Capital One

Capital One’s DevOps transformation strategy

Creating cross-functional teams

Leveraging microservices architecture

Building an on-demand infrastructure on AWS

Automating delivery pipelines using Jenkins

Governance within Capitol One’s CI/CD pipelines

Implementing chaos engineering

Embedding security principles in DevOps workflows

What can we learn from Capital One’s DevOps transformation?

Summary

Questions

7

A Practical Pipeline for Technical Release Managers

Provisioning the AWS infrastructure

Prerequisites

Step 1 – fork the repository

Step 2 – create a default VPC

Step 3 – create an HTTP rule in the default security group

Step 4 – create an ECR registry

Step 5 – create an ECS cluster

Step 6 – create an ECS task definition

Step 7 – create an ECS service

Configuring the GitHub Actions workflow

Prerequisites

Step 1 – configure the necessary GitHub repository variables and secrets

Step 2 – kick off a GitHub Actions workflow

Step 3 – analyze deployment logs

Step 4 – observe the deployed application running in AWS ECS

Summary

Resources

Questions

8

How CI/CD Pipelines Enforce Good DevOps Release Management

Understanding CI/CD governance

The OWASP Top 10 CI/CD Security Risks

Speed-to-market versus governance

Three common paths to CI/CD governance

Common CI/CD governance obstacles

Creating an enterprise CI/CD governance model

Understanding branching strategies

Choosing a branching strategy

Common DevOps branching strategies

How to choose your branching strategy

Exploring release pipelines

Tasks

Artifact store

Configuration store

Logging

Workflow execution

The difference between deployment and release

Understanding change management

Implementing a change approval process

Obstacles to implementing change approval

Methods to enhance the change approval process

Summary

Questions

Part 3: Develop a Culture of DevOps in Your Organization’s Release Management Strategy

9

Embracing DevOps Culture in Your Release Management Strategy

Faster and cheaper doesn’t always mean better

Never compromise on quality

Project timelines are negotiable

The problem of perception in DevOps

DevOps is more than just tools and processes

Adopting the CALMS approach

Culture

Automation

Lean

Measurement

Sharing

What to keep in mind when adopting CALMS for DevOps

It takes time to develop a DevOps mindset

Summary

Questions

10

What Does Receiving Support from Leadership and Stakeholders Look Like?

Making investments in people and technology that are deftly aligned

Why empowerment, ethics, trust, and patience are highly valued

Communication in a DevOps environment

Understanding why building trust is the key to your success

Leaders of DevOps establishments require soft skills

Offering the team autonomy, ownership, and shared responsibility

Making customer feedback the center of every strategy

What is a feedback loop?

Collecting customer feedback the DevOps way

Incorporating customer feedback into your decision-making processes

Summary

Questions

11

Overcoming Common Pitfalls in DevOps Release Management

Having a carefully designed change management process

Employees must comprehend the rationale for change management initiatives

Executives operate outside of their comfort zone, while others...

Leaders aren’t candid about the difficulties they face

Employee temperaments are resistant to change

Following a release checklist

Successful releases go far beyond following a checklist

Exploring 10 common pitfalls of DevOps release management

A lack of support from leadership

Thinking DevOps is mainly about tools

Treating DevOps and CI/CD as the same thing

Quality as an afterthought

Lacking dashboarding and reporting, or having too much

Selecting the wrong metrics to measure project success

Leaving others behind as you move forward with DevOps

Converting to microservices from old infrastructure and design

Deciding to automate the wrong processes

A quiet customer is a happy customer

Summary

Conclusion

Questions

Appendix

The OWASP Top 10 CI/CD Security Risks

Insufficient Flow Control Mechanisms (CICD-SEC-1)

Inadequate Identity and Access Management (CICD-SEC-2)

Dependency Chain Abuse (CICD-SEC-3)

Poisoned Pipeline Execution (CICD-SEC-4)

Insufficient Pipeline-Based Access Controls (CICD-SEC-5)

Insufficient Credential Hygiene (CICD-SEC-6)

Insecure System Configuration (CICD-SEC-7)

Ungoverned Usage of 3rd Party Services (CICD-SEC-8)

Improper Artifact Integrity Validation (CICD-SEC-9)

Insufficient Logging and Visibility (CICD-SEC-10)

Value stream mapping

Waste

Value

Continuous flow and continuous improvement

Release management templates

Software release checklist

Business specification document

Software Requirements Specification (SRS)

Requirement traceability matrix document

Use case document

Answers to chapter questions

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Chapter 7

Chapter 8

Chapter 9

Chapter 10

Chapter 11

Glossary of terms

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

R

S

T

U

V

W

Y

Index

Other Books You May Enjoy

Preface

To streamline the complexity of building and maintaining modern applications, demand for the role of DevOps engineer has blossomed. This way of thinking focuses on shrinking the bottlenecks between IT operations and software development, having its origins in lean manufacturing concepts.

By embracing DevOps release management, software development teams benefit from incorporating quality checks and shifting left, by moving testing, automation, and QA procedures much earlier into the software development life cycle. However, release management still requires monitoring applications and infrastructure components, in addition to managing change orders and schedules.

In this book, you will learn a brief history of release management, what DevOps release management is, how it is unique, and basic strategies to implement it. You will be shown how CI/CD pipelines enforce good DevOps release management and learn techniques to optimize them. Lastly, you will learn how to create a culture of cross-functional product development that reduces waste and increases value to the customer. Because of its usefulness in removing silos that isolate team members, DevOps release management is emerging as the most popular strategy currently being adopted.

Who this book is for

This book is intended for DevOps engineers, software engineers, project managers, QA testers, and product managers who are responsible for the development, quality assurance, release, and deployment of software products. The book will also be useful for teachers, students, and researchers studying computer science or business management.

DevOps and release management share an affinity with regard to software development, project management, and IT operations. DevOps release management encompasses activities involved in overseeing the design, planning, scheduling, testing, and implementation of the software release and delivery cycle.

This book is a comprehensive introduction for those who are new to DevOps release management. You will learn key skills to shift left, building quality products in record time. You will gain the knowledge needed to start your own DevOps release management initiative and the confidence to transform your company.

What this book covers

Chapter 1, Understanding the Software Development Life Cycle, provides an overview of the Software Development Life Cycle (SDLC), the software industry’s procedure for creating new software. This technique ensures that software developers build high-quality, low-cost products in the shortest amount of time possible.

Chapter 2, A Brief Introduction to Release Management, defines what release management is, its cultural significance, and its technical perspective. We’ll also review a brief history of release management and understand how it has evolved over the years, including a review of the standard six phases of any release management model.

Chapter 3, What Are the Various SDLC Release Management Models?, covers release management models such as ITIL, Waterfall, iterative, V-shaped, spiral, big bang, Agile, and DevOps.

Chapter 4, What Problems Does DevOps Release Management Try to Solve?, makes the case for why the qualities of DevOps differentiate it as a superior release management methodology by incorporating automation, minimizing risk, streamlining releases, and measuring success by tracking metrics and analyzing key performance indicators.

Chapter 5, Understanding What Makes DevOps Release Management Unique, discusses how release management is a holistic practice, taking every component of a value stream into account. DevOps integrates CI, CD, QA, security, and feedback, through the use of well-crafted, automated pipelines and a carefully selected patchwork of testing and approval processes.

Chapter 6, Understanding the Basics of CI/CD, explores CI/CD, a key strategy of DevOps release management. It automates the majority of manual human intervention that would traditionally be needed in order to produce a new software release or get new code into production.

Chapter 7, A Practical Pipeline for Technical Release Managers, will be a little different from the rest of this book. You will be shown how to build a Docker image containing a simple web application that deploys to AWS ECS, using GitHub Actions.

Chapter 8, How CI/CD Pipelines Enforce Good DevOps Release Management, covers topics including managing speed-to-market and CI/CD governance, developing your team’s branching strategy, constructing release pipelines, and implementing a change approval process that is appropriate for DevOps release management!

Chapter 9, Embracing DevOps Culture in Your Release Management Strategy, discusses developing a DevOps culture, with thorough planning and a unified approach. You’ll be shown how to get buy-in from executive leadership, form a DevOps team from the ground up, and gradually define processes that foster a culture of collaboration and continuous improvement.

Chapter 10, What Does Receiving Support from Leadership and Stakeholders Look Like, discusses how DevOps culture necessitates the unwavering backing and active involvement of the leadership within the organization. If these individuals do not wholeheartedly support and commit to the DevOps initiative, there is a significant likelihood of its failure.

Chapter 11,Overcoming Common Pitfalls in DevOps Release Management, looks at aspects such as aligning with an organization’s unique culture, working style, and software release objectives to avoid common pitfalls in DevOps release management. If you look at enough DevOps-centric establishments, you’ll notice that they encounter several common pitfalls over the course of their operations.

Appendix, contains a glossary of terms, answers to chapter questions, additional content, and templates of common documents that release managers use in their daily activities.

To get the most out of this book

Basic knowledge of software development and product development is required to work with the content of the book. However, having a basic knowledge of DevOps practices will help the reader follow the exercises in the book. References will be provided for those new to these strategies. By having previous experience working in an Agile or DevOps environment, you will be in a good position to understand the concepts covered herein.

If you are using the digital version of this book, we advise you to type the code yourself or access the code via the GitHub repository (link available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Embracing-DevOps-Release-Management. If there’s an update to the code, it will be updated in the existing GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “From GitHub, click on the task-definition.json file, within this repository.”

A block of code is set as follows:

...    - name: Build, tag, and push image to Amazon ECR       id: build-image       env:         ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}

Bold: Indicates a new term, an important word, or words that you see onscreen. For example, words in menus or dialog boxes appear in the text like this. Here is an example: “Expand Monitoring, and then toggle Use Container Insights on to enable Container Insights.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Embracing DevOps Release Management, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application. 

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/978-1-83546-185-3

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Understanding the Software Development Life Cycle and Its Design

In this first section of the book, we’ll begin by exploring the Software Development Life Cycle (SDLC) and why it is so important. Then, we’ll briefly introduce you to Release Management and the common Release Management Life Cycle phases. Next, we’ll dive in to discover how various SDLC Release Management models work. Although this book is concerned with DevOps Release Management, it is crucial to understand the SDLC first, how it relates to Release Management, and where both fit into the overall project management landscape.

This section contains the following chapters:

Chapter 1, Understanding the Software Development Life CycleChapter 2, A Brief Introduction to Release ManagementChapter 3, What Are the Various SDLC Release Management Models?

1

Understanding the Software Development Life Cycle

The software development life cycle (SDLC) is the software industry’s procedure for creating new software. This technique ensures that software developers build high-quality, competitively priced products in the shortest amount of time possible.

The SDLC encompasses various stages, such as planning, writing, testing, and maintaining code. Software engineers adhere to the software development life cycle to conceptualize and develop software applications for many platforms, including laptop and desktop computers, cloud infrastructure, mobile devices, video gaming systems, kiosks, and other technology platforms. The concept of “life cycle” was initially introduced during the 1950s to delineate the several phases associated with the creation of a novel computer system. However, it has since become widely adopted to encompass all stages in the production of software.

Although this book is concerned with DevOps release management, it is crucial to understand the software development life cycle first, how it relates to release management, and where both fit into the overall project management landscape. In a nutshell, SDLC is a powerful tool in the project management utility belt. It improves the focus and efficiency of everyone on the team, maximizing their productivity.

In this first chapter, you will learn the following:

The definition of the SDLCThe seven phases of the SDLCThe SDLC versus other life cycle management methodologies

Defining SDLC and looking at its seven phases

The SDLC refers to the systematic approach that development teams use to produce high-quality software with optimal cost efficiency. The primary goal is to mitigate risk and ensure that the software being developed surpasses the customer’s expectations. Using this method, you will first create a comprehensive strategy that will direct product development, and then you will break it all down into more manageable components that can be scheduled, finished, and measured.

The SDLC can be understood as a conceptual framework that outlines the many stages encompassed by a chosen methodology rather than being a methodology in and of itself. That is to say, the SDLC process exhibits variations across different teams and products. Nevertheless, it is worth noting that many of the same stages are commonly shared among the majority of SDLC models that are in common practice today. These stages include planning and analysis, design, build, testing, implementation,and maintenance/support.

Figure 1.1: The seven stages of the SDLC

1. Planning and Analysis

The first phase of the SDLC is the project planning stage, where you gather business requirements from your clients and stakeholders. The primary objective of this phase is to enable you to define the fundamental problem a customer is facing and discover appropriate solutions. Planning facilitates the identification of the essential components that are necessary for the development of a new system, enabling the fulfillment of project requirements by applying a deliberate and methodical process. Analysis allows you to acquire the necessary resources before starting a new software development endeavor. At this point, calculations are made regarding the resources, costs, and time required to successfully complete the project.

In order to effectively determine the scope of production, prioritize production items, and establish a development cadence, business analysts engage with their customers to collect requirements, determine the target demographic, and consult with industry professionals. All of this is done with the objective of formulating a comprehensive business specification (BS) document. This document may be commonly referred to as the customer requirement specification (CRS) by various organizations and teams. It should be noted that although creating a BS document is considered good practice, some development teams may choose to forgo using one, opting instead for a less formal approach, as you will soon discover.

The goal of a BS document is so that you can provide a list of client problems that currently exist so that programmers can fix them using software. It can be a valuable tool in assisting the group in thinking outside of the box about how to make products better. You should hand off the document to the development team once it has been determined that the software project is in line with the business and stakeholder goals, is feasible to construct, and fulfills user demands.

2. Define Requirements

The aforementioned phase is significant as it facilitates the transformation of the data that you’ve acquired during the planning and analysis phase into well-defined requirements for the team members who are responsible for development. Defining requirements facilitates the creation of many important documents, including a software requirement specification (SRS), a use case document, and a requirement traceability matrix document, if needed.

According to the business specification document, senior members of the development team collaborate with stakeholders and specialists to plan the software development project. The project could be about making a new software product or making an existing one even better. Identifying potential difficulties at this early stage is crucial. If a problem is discovered, managers and developers propose various solutions, which are then presented and analyzed in order to identify optimal alternatives.

During this preliminary stage of development, team members collaborate on comprehensive plans related to the following:

The intentions behind the projectThe requirements of the projectAnticipated issuesOpportunitiesRisks

The primary objective of this stage is to accurately determine the functional requirements for a project. Performing this necessary analysis ensures that the final deliverable aligns with the specific requirements and expectations of your clients and includes the proactive measures that must be taken in order to guarantee the fulfillment of your customers’ needs and preferences.

In short, this SDLC stage is employed as a comprehensive technical blueprint wherein clients articulate their expectations, requirements, and demands for the project. By defining all of these elements, you can ensure that all elements of your software projects receive equitable consideration during the design and development process.

3. Design

The design stage is when you begin translating ideas into a tangible form. The initial strategy and vision are further developed and documented in the form of a software design document (SDD) that defines several aspects, such as system architecture, programming language selection, template utilization, platform choice, and the implementation of application security measures. This is also the location where you can create diagrams and flowcharts that illustrate the software’s response to user activities. Sometimes, the design process includes the creation of a minimum viable product or proof-of-concept. A pre-production version of the product can help you imagine how the final product will look. This helps to keep any required adjustments minor and also helps the team avoid having to completely rewrite the code from scratch.

The SDD will play a vital role in the production process, particularly in the development stage (see stage 4). Developers will rely heavily on the SDD as their primary reference to write their code. In order to mitigate any potential issues and risks identified in the earlier phases, you must also consult the SRS document as well. It serves as a reference point for designing the product, ensuring that it incorporates measures that shield the team from any potential risks identified earlier.

A real-world example that showcases the design phase’s usefulness is exemplified by how local and federal government agencies use it to establish scalable frameworks that are consistent and repeatable. To accomplish this, the design phase of the SDLC might consist of pre-arranged templates and guidelines created by centralized departments that offer structured content used to define, implement, and communicate all project aspects. For example, this helps scale software applications that are used to issue and manage driver’s licenses, voter registration cards, and library cards that are all interoperable across multiple jurisdictions. This is particularly useful in the case of disparate jurisdictions that are managed with varying levels of resources and different styles of leadership, but they must remain federated. This level of forethought helps determine the costs associated with real-world implementation or ensure that the end result serves all stakeholders involved.

One thing to keep in mind during the third stage of the SDLC is that the end-users should have an opportunity to review the design and articulate any modifications to the intended system. Here, you will work together to create the final technical design documents before going into production. At this point, all of the necessary requirements for developing new software or systems should be established, and a backlog of work can be created.

4. Development

The fourth phase of the SDLC is where most of the work on a project really begins in earnest. A team of programmers, systems engineers, and business developers collaborate together and begin the process of software development. At this point, a Gannt chart or Kanban board is typically created to make sure that work on the project follows a smooth cadence. Development teams will typically organize their work using one of two approaches: through the implementation of sprints or as a sustained, continuous development endeavor. Regardless of the method employed, teams will strive to complete tasks as quickly as possible.

Important note

Sprints: A sprint is a limited amount of time that development teams have to get a certain amount of work done. Sprint duration can vary from one week to one month but is typically about two weeks. The short time constraint of a sprint encourages developers to prioritize the release of modest, incremental improvements over the release of large, sweeping changes. Because of this, less time is spent debugging the program, and the end-user experience is improved.

Continuous development: Software development approaches that use continuous development and agility share many similarities. Instead of making massive, all-at-once improvements to software, incremental ones are produced on a continuous basis, allowing for code to be released to users as soon as it is complete and tested. Software development, testing, and releasing updates to production environments can all be streamlined and automated using continuous development.

During the development stage, the product code is written in accordance with the SDD (see stage 3) so that the product can be manufactured efficiently. This involves the development team building out a new system from the ground up or approaching an existing project with new requirements and fresh perspectives. This may include facilitating a smooth and cost-effective digital transformation from an existing system to a new one in the cloud.

During this stage, developers break down the project into smaller software components that will eventually become the finished product. In order to construct the code, developers make use of a wide variety of tools and computer languages. These are chosen in accordance with the prerequisites of the software products that are being built.

Some of the programming tools may involve the following:

Integrated development environments (IDEs):EclipseMicrosoft Visual StudioPyCharmVersion control systems:GitGitHubGitlabBitbucket

Some of the more common programming languages may include the following:

C#C++PythonJavaScriptGo

Close involvement from senior leadership in this phase is crucial for reaching the project’s goals because this step of the SDLC can consume a significant amount of time. It is essential that you have a predetermined timeframe as well as milestones in place so that the software developers know what the objectives are, and so you can monitor how they’re progressing. By the end of this phase, the bulk of the product code will be completed.

In certain instances, the development phase may coincide with the testing phase, during which specific tests are conducted to ensure the absence of significant software defects.

5. Testing

The production of software without conducting a thorough testing of its features and functionality is both untenable and ill-advised; the fifth phase is dedicated to testing. To confirm that everything is working properly, QA engineers will conduct an assortment of tests, which include code analysis, security, integration, performance, and functional tests. Bugs and defects can be successfully resolved through repeated testing and analysis. Until a system’s design satisfies a client’s requirements, continuous testing is something that you’ll want to be doing. Performing manual software testing by the team is better than no testing at all, but preferentially, it should all be automated where possible.

Product testing should be performed by your quality assurance team before releasing the software into a production environment to ensure that it is fully functional and accomplishes its intended goals. Major problems with the user experience or security can also be worked out during the testing phase. In any case, proper testing will guarantee that every component of the software performs as expected. The final step of a product’s development includes validation, verification, and user acceptance testing. If the product makes it this far, it is likely ready for release.

Including testing, the software should be subjected to a formal quality assurance (QA) procedure to certify the product’s quality. Software testing will usually consist of the following kinds of tests:

Performance testing: Performance testing is a commonly employed testing strategy that aims to assess the responsiveness and stability of a system when subjected to a specific workload. Additionally, it can be utilized to examine, quantify, authenticate, or corroborate several other system quality features, including scalability, dependability, and resource utilization.Functional testing: Functional testing, or black-box testing, is a quality assurance process that creates test cases based on the documented requirements of the software component being evaluated. The purpose of functional software testing is to determine whether or not a system or its individual parts meet predefined functional requirements. The functions are tested by observing their responses to input, and the underlying structure of the code is rarely taken into account.Security testing: Security testing helps information systems safeguard data and work properly by detecting security issues. Due to the logical limits of security testing, passing does not guarantee that the system is flawless or meets security criteria. Security needs may include confidentiality, integrity, authentication, availability, authorization, and non-repudiation. System security requirements determine the security requirements to be tested. Security testing has many definitions and methods. By establishing a foundation, a security taxonomy helps us grasp these techniques and meanings.Unit-testing: Unit testing is a technique for verifying the quality of software by evaluating discrete sections of code, or “units of source code,” such as one or more computer program modules, along with their corresponding control data, usage processes, and operating procedures.UI/UX testing: In user interface (UI) testing, testers verify that on-screen elements, including buttons, fields, and labels, perform as expected. Screens that have controls, such as toolbars, colors, typefaces, sizes, buttons, and icons, are tested for their responsiveness to user input as part of UI testing. The purpose of UI testing software is to simulate the end user’s experience with a product or service.Regression testing: Regression testing involves performing both functional and non-functional tests again after a change has been made to confirm that the program continues to function as expected. A software regression is a type of software bug where a feature that has worked before stops working. Software updates, feature additions, and even minor configuration tweaks can all necessitate additional testing to ensure compatibility. Test automation is commonly used in regression testing due to the exponential growth of test suites with each fault discovered.User acceptance testing: The final stage of software development is user acceptance testing (UAT), where end users and clients evaluate the product in real-world scenarios to assess its functionality and utility. UAT focuses on whether a piece of software can work in users’ real-world systems, not its design or functionality. Development teams must execute UAT because their software assumptions may not hold true in their daily work owing to miscommunication, misunderstanding, oversight, or changing needs. Beta testers, in real-world situations, test software and give developers input during UAT to fix any flaws before release.

6. Deployment

After testing is completed, the product gets released to the market, but that could simply be internally within the organization where you work. Depending on the business model, product deployment may involve numerous steps or employ many tactics ranging from a big bang to a rolling release or something in between. There will be more time for testing if the product is launched in stages, such as blue/green or canary deployments. The release of the final product or the need for further adjustments to the code is contingent on what feedback is received. The deployment stage usually yields some measure of unknown, undesirable outcomes that you should anticipate.

7. Maintenance

In the seventh SDLC stage, maintenance and upgrades are prioritized. At this point, the system can be tuned for better performance, and new capabilities can be added over time. The software deployment will undergo continuous monitoring to mitigate potential performance and security concerns. Additionally, it is critical that administrators or site reliability engineers promptly report any instances of bugs or defects once they are discovered so that they can be fixed as soon as possible.

Customers will utilize a software product in different ways based on their own individual requirements; this means that there may be specific problems that need fixing. This is because it is possible that users will discover the flaws and defects that developers and testers missed. In order to enhance user experiences and improve user retention, it is crucial to address and resolve these flaws immediately. In particular cases, these conditions may necessitate a return to the first phase of the software development life cycle. Each of the phases of the SDLC can also be restarted for any new features that you might wish to add in subsequent releases and upgrades of the software product that you are supporting.

It is generally agreed that the maintenance phase is the very last stage of the SDLC. This is especially true if your software development process follows waterfall release management. That being said, the industry is shifting towards a more agile approach to software development, such as DevOps, in which maintenance is merely an iterative step towards further enhancement.

Defining some commonly used terms

Here’s a quick list of some terms and their definitions that you will often come across over the course of this book:

Big bang: The big bang approach lacks the process-oriented characteristics of other release management models, and no advance preparation is needed. Software development is the primary focus of this strategy, which allows programmers to bypass the planning phase and move directly into code production.Rolling release: A rolling release, often referred to as a rolling update, is a type of software development model. Software improvements are developed in ongoing, incremental steps rather than in discrete version releases. Users can upgrade the program at any moment to get the most recent version, and they are encouraged to do so often.Blue/green deployments: Blue/green deployments produce two identical environments. One environment (blue) runs the existing program version, and one (green) runs the new one. After testing passes on the green environment, live application traffic is directed there, and the blue environment is depreciated. By simplifying rollbacks if deployments fail, blue/green deployment strategies boost application availability and reduce deployment risk.Canary deployments: A canary deployment refers to a gradual and controlled release strategy for an application, wherein traffic is divided between an existing version and a new version. This approach involves initially introducing the new version to a subset of users before expanding its deployment to the entire user base. By following this approach, one can determine the reliability of the updated version of the application prior to its widespread distribution to consumers.

At the end of the deployment phase, your final product is delivered to your end users. At this point, deployment engineers set up the software at the business and/or provide users with assistance in getting the program up and running. Depending on the kind of SRLC that your team is following, you can automate this procedure and schedule your deployment. For instance, in the case of implementing a single feature update, it is possible to execute this process by initially releasing it to a limited subset of customers; this is referred to as a “canary release,” as mentioned earlier. If you are creating brand-new software, you may opt to roll it out internally as an alpha release first. We’ll briefly expand on SRLC later, but this topic is considered out of the scope of the subject of this book.

Now that we have covered the seven stages of SDLC, let’s see where it stands in comparison with the other life cycle management methodologies.

SDLC versus other life cycle management methodologies

If you are familiar with product management concepts, you know that SDLC is not the only life cycle management procedure out there. Here are some related concepts and what sets them apart from SDLC.

Software development Life Cycle versus systems development life cycle

The systems development life cycle is the process of planning and constructing an information technology system. On occasion, people will refer to this process by the acronym SDLC; do you see how this can be confusing when referring to the software development life cycle? In terms of systems development, a system will generally be comprised of many individual hardware and software components that each collaborate together, executing sophisticated tasks and computations. Just know that when you see the acronym SDLC, be on the lookout for context clues in the literature so that you can properly distinguish if what you are reading is referring to software development or systems development.

Important note

In this book, we will refer to the software development life cycle as SDLC.

There are some key differences between the SDLC and the systems development life cycle. The SDLC is limited to the creation and testing of software components. In contrast, systems development incorporates the setup and management of the hardware, software, people, and processes required for a complete system. Further, the SDLC places its whole emphasis on the program itself, while systems development may encompass activities such as organizational training and change management that are not always associated with software development.

SDLC versus release management

Release management refers to the systematic supervision and control of the SDLC. The responsibilities encompass overseeing the various stages of software product development, namely planning, designing, testing, deploying, and releasing. The inclusion of release management is a vital component that is complementary to the SDLC. The primary objective of release management is to guarantee that the development team effectively fulfills the business objectives and produces software of exceptional quality. In summary, release management serves as a crucial intermediary between the development and operations domains.

There are some key differences between SDLC and release management. The primary goal of SDLC is to mitigate risk and keep the development effort well-structured. In contrast, the primary objective of release management is to ensure that the development team is well organized and successfully fulfills the business objectives. Also, SDLC is primarily focused on the continuous integration of new software, while release management is focused on its continuous delivery. Both, however, fall under the jurisdiction of a Release or Project Manager.

SDLC versus ALM (application Life Cycle management)

Application life cycle management (ALM) is a comprehensive concept encompassing the entire process of software application development, spanning from the initial idea generation and design phase through development, testing, production, support, and ultimately, the retirement of the program. The concept being discussed bears a resemblance to the SDLC. Although they may exhibit similarities when examined superficially, it is important to note that there are several significant distinctions between them.

The SDLC primarily emphasizes the development phase of an application, whereas ALM adopts a more holistic approach, encompassing the entirety of the program’s life cycle. The effective management of various stages of application development requires the collaboration and integration of several ALM tools, procedures, and teams. Note that it is possible for an application’s life cycle to encompass numerous SDLCs inside the broader ALM framework.

SDLC versus PDLC (product development life cycle)

The product development life cycle is a thorough process that spans the whole life cycle of a product, beginning with the conception of an idea and ending with the product being phased out of production. This includes activities such as product planning, market research, product design, development, testing, launch, marketing, and support.

There are some key differences between SDLC and PDLC. SDLC is primarily concerned with the process of developing software, whereas PDLC primarily focuses on the whole development of a product. Moreover, SDLC encompasses several distinct stages, including planning, design, coding, testing, and deployment. In contrast, the PDLC incorporates supplementary phases, such as market research, product planning, and product marketing. Further, SDLC is designed to develop software that aligns with the specific requirements of the end user. On the other hand, PDLC is focused on creating a product that fulfills the demands of the market and generates revenue for the business.

SDLC versus SRLC (software release life cycle)

Gathering, documenting, and validating software requirements are the primary goals of the software release life cycle (SRLC). Methods for gathering requirements from various parties, sorting them by order of importance, writing them down in a requirements specification, and checking their accuracy are all part of this process.

There are some key differences between SDLC and SRLC. In contrast to the SDLC, the SRLC is concerned with managing software requirements. The SDLC is comprised of stages such as planning, design, coding, testing, and deployment, whereas the SRLC adds stages such as requirements elicitation, analysis, and validation. While SDLC strives to create software that satisfies the needs of its users, SRLC checks that those needs are well-defined before any coding is done.

Release management versus change management

Release management and change management are two critical processes that play a vital role in the successful delivery of software updates and enhancements to customers.

The domains of release management and change management are interconnected, albeit with distinct scopes and aims. The primary objective of release management is to oversee the comprehensive delivery of software releases, whereas change management is primarily concerned with managing the various changes that collectively constitute a release. Release management primarily focuses on the technical aspects of software releases, encompassing elements such as the release schedule, environment, and deployment. Conversely, change management primarily addresses the business aspects of software changes, including change request, approval, and communication. Release management and change management encompass distinct roles and duties, including release managers, release engineers, change managers, change analysts, and change reviewers.

Release management refers to the systematic approach of organizing, coordinating, evaluating, and implementing software releases across several environments, including development, testing, staging, and production. The primary objective of release management is to guarantee the timely delivery of software releases while adhering to budgetary constraints and minimizing any potential disruptions experienced by end users. New features, bug fixes, enhancements, and configuration changes are all examples of the kinds of changes that change management aims to keep track of. The purpose of change management is to get changes accepted, documented, and communicated to the appropriate parties so that they can have the greatest possible positive impact on the business and its goals, requirements, and standards. It is important to test and verify any modifications to a software system before deploying them, which is what change management is all about.

Release management versus project management

The term release management is used to describe the process of overseeing the creation and distribution of software releases, including its planning, scheduling, testing, and deployment. It improves the speed and quality of software products and upgrades that are delivered by development teams. Release management, in a nutshell, is the process of ensuring a smooth transition from development through staging to production. In a broader sense, the goal of project management is to ensure the success of a specific project within the parameters of a scope that has been established in advance. The planning of time limits, schedules, finances, and communication are all included in this aspect. Any time a product receives a new version or update, that counts as a part of the project.

Together, project management and release management increase a team’s odds of successfully completing a project. Release management is similar to project management in that it has a defined structure and a series of phases, even though the methods themselves are unique. Examples of project management methodologies include the following:

ScrumLeanSix SigmaExtreme Programming (XP)PriSMPRINCE2

This concludes Chapter 1. In this first chapter, you learned the definition of the software development life cycle (SDLC), and you explored its seven phases. Finally, you’ve learned how the SDLC differs from other life cycle management methodologies. In the next chapter, we’ll take a detailed look at software release management to understand its meaning.

Summary

Effective project management is possible with the help of an SDLC strategy. Managers, designers, developers, and clients all benefit from the comprehensive foundation provided by this tool. The seven stages of the SDLC are all essential, and they build on one another.

In the model’s initial phase, senior members are in charge of gathering requirements. Meanwhile, IT professionals amass all the data and resources they will need during the product’s lifespan. After determining what information is needed, the appropriate documents are drafted. The subsequent stages involve the design and coding processes, followed by the testing phase to evaluate the software’s functionality. The final stages are deployment and maintenance. The team has the choice to utilize various models, including the widely recognized waterfall and agile methodologies. When it comes to developing software, adhering to an SDLC is key. As mentioned, acquiring knowledge about the different stages of the SDLC is an effective approach for a product manager to establish a common understanding and connections between the cross-functional and customer-centric activities inside the SDLC. This facilitates the clear division of the product inside the wider range of corporate objectives, plans, and endeavors.

Questions

What is the definition of the SDLC?What are the seven phases of the SDLC?What is the difference between the SDLC and the systems development life cycle?What is the difference between the software development life cycle and release management?What is the difference between the SDLC and application life cycle management?What is the difference between the SDLC and the product development life cycle?What is the difference between release management and change management?What is the difference between release management and project management?What is the difference between a blue/green deployment and a canary deployment?What are the seven phases of the SDLC?

2

A Brief Introduction to Release Management

A new or improved software product is referred to as a release in the discipline of software engineering. This comprises any and all associated procedures and artifacts that are necessary for its development.

A release is the climax of the software development and engineering process, and it represents an iteration of the product that is both comprehensive and fully functional. Before software products are made available to the general public, they will typically go through the alpha and beta testing phases. A release is typically reserved for the final, polished version of the software, though it can also be used to describe the debut of an alpha or beta version as well. You may also encounter the phrases “launches” and “increments” when discussing releases as well.

Most companies use a system of sequential numbers or letters to label their releases. The term software versioning describes this naming convention. Each organization consistently applies its own internal standard, but semantic versioning (semver) is the common industry-wide standard for how these unique IDs should evolve from release to release.

In this chapter, we will define release management and learn its cultural significance and technical perspective. Further, we’ll review a brief history of release management and understand how it evolved over the years. Finally, you’ll look at the standard six phases of any release management model. It is important to note that Waterfall was the original release management standard, but using Waterfall is not obligatory. Release management is agnostic of your chosen model and is adaptable to many kinds of SDLC models, which we will cover more in Chapter 3.

These are the main topics that we will cover in this chapter:

What is release management, and how did it evolve? Dissecting the release management life cycle

What is release management, and how did it evolve?

Release management is a comprehensive set of activities that involve strategic planning, conceptualization, scheduling, rigorous testing, seamless deployment, and the effective control of a software release. The primary objective of this practice is to facilitate the quick delivery of essential application features and enhancements to the customer by software development teams while simultaneously upholding the integrity, confidentiality, and availability of an established production environment.

In the competitive landscape of business and IT, product releases that lack quality or features are the quickest way to give your competitor an advantage. Modern enterprises are dynamic, and multitudes of changes get completed at varying paces. Enterprises need release control and deployment automation to orchestrate all of these changes so that the final product delivers the exceptional value that their customers expect. Successful release management enhances the frequency with which releases are completed and decreases the frequency with which quality issues arise for a business. As a result, businesses can provide software more quickly while also reducing the associated risks, yielding increased productivity, communication, and co-operation.

Because of these enhancements, the team is now able to generate high-quality software on a consistent basis in far less time than before, which enables the organization to be more responsive to the demands of customers or changes in the operational environment. Standardizing and streamlining the development and operations process is another benefit of release management. The group establishes release controls that can be audited, resulting in a central location from which all releases can be retrieved. The maturity of an organization can be further improved by instituting a standard, written procedure for all releases to follow. Teams can learn more from past releases and apply that knowledge to future iterations if they standardize and concentrate on the product.

The improved communication between operations and developers is well-received because it results in fewer surprises. Now, cross-functional teams will not have to worry about operations being left to patch and pray or fight fires because of missed deadlines after a release has been thrown over the wall from development. As a result, more time is available for automating business processes or fixing incompatibilities in the configurations of integrations in the development and