Back Matter

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

10. Operating and Monitoring the Release

Afterword

This text builds on a host of prior industry work. None of the ideas in this book are inventions or completely original. This book represents a synthesis of ideas from all corners of the software industry across multiple platforms. Coupled with experience, success, and failure, this book provides the best rules of thumb that can be mustered at this time.

The following is a short summary of the prior works and events that were highly influential in the experience that led to this book.

In 2001, a group of software industry leaders met at a ski resort to mull over the problems in their field that had been building throughout the 1990s and the infamous dot-com bubble of the late 1990s. This group produced the Manifesto for Agile Software Development ( www.agilemanifesto.org ). These principles have redefined the way the industry organizes and executes software development work. A fundamental premise of agile development is to organize and perform work in much smaller batches than had previously been used in the late 1990s. Now, units of software delivery called “sprints” or “iterations” are commonly discussed. Many organizations run in cadences of iterations that are 1–3 weeks in length. The unit of software changes has likewise shrunk. Now developers target changes that can be accomplished in the current iteration, and many teams experiment with just how small software changes can be while keeping the software stable and releasable at all times.

In 2004, Michael Feathers wrote Working Effectively with Legacy Code . The book was released in the years following the Manifesto for Agile Software Development , and it addressed a common situation that many organizations were faced with: How can I change my software when every change generates at least two new defects? As teams were attempting to make changes and restabilize their software, they realized that previous engineering methods were insufficient when attempting to drive cycle times down to less than a month. Feathers describes methods for breaking apart code bases that were never intended to execute outside of a completely integrated production environment. The author summarizes that without running the software within automated test harnesses, any piece of software, however new, is destined to become labeled as “legacy code;” unchangeable, brittle, and expensive to maintain. He described techniques illustrating how to insert seams into existing code in order to retrofit tests. Then, armed with tests that protected the functionality, the software could be changed with less fear. Michael Feathers was also the author of some early unit testing framework for C++, namely, CppUnit.

In 2006, Paul M. Duvall, Steve Matyas, and Andrew Glover wrote Continuous Integration: Improving Software Quality and Reducing Risk . This influential work illustrated a method that some in the industry had been perfecting called continuous integration (CI) . This method sought to run an automated build of the software application every time any change was committed to the version control system. The book illustrates some specific engineering methods that have to be adopted. A ground-shaking inclusion was the premise that the continuous integration build must include building and testing dependencies that an application owns, including relational databases and other storage mechanisms. The authors dedicated an entire chapter (Chapter 5 ) to continuous database integration .

Additionally, in 2006 Martin Fowler penned an article titled Continuous Integration ( www.martinfowler.com/articles/continuousIntegration.html ). In this article, he proposes some standards for a continuous integration build:

Maintain a single source repository
Automate the build
Make your build self-testing
Everyone commits to the mainline every day
Every commit should build the mainline on an integration machine
Fix broken builds immediately
Keep the build fast
Test in a clone of the production environment
Make it easy for anyone to get the latest executable
Everyone can see what’s happening
Automate deployment

While many in the industry were innovating new and better methods for shortening cycle time, 2006 was the year when successful and proven methods were being shared openly and published widely. Continuous integration included the automated deployment of software releases. In the years that followed, continuous integration became known as continuous delivery , expressly implying the inclusion of software deployments all the way to end users in production environments. Some refer to the method as CI/CD , illustrating the confusion that exists to this day about where CI stopped and CD started. Both refer to the full process of integrating source code from multiple developers and providing new working software to end users. However, in the common lexicon, most refer to the “CI build” and then refer to a CD pipeline that deploys across successive environments. Historically, however, continuous integration, as a method, in 2006 included automated deployments to production.

The year 2009 saw another seminal work published. Jez Humble and David Farley authored Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation . This book cited the 2006 book on continuous integration and pulled the story forward by proposing methods by which to not only build continuously but also to continuously deploy to downstream environments. More proven methods for handling deployment scenarios were included. The stages proposed in this book are

Version control
Commit stage
Automated acceptance tests
Manual validations
Release (production)

This process is much more high level, but the commit stage includes the private build and the integration build, and the automated acceptance tests are prescribed to be run against a fully deployed pre-production environment.

In 2009, the term DevOps was coined by Patrick Debois when he organized the first DevOpsDays conference in Ghent, Belgium. The current body of DevOps-focused works and events has grown substantially over the last 10 years.

Index

A

az command

Azure App Service

creating web app

az command

using Cloud Shell

using command shell

deployment slots

compare browser windows

creating stage slot

test app

Visual Studio

Azure pipeline, deployment

acceptance tests

application component

ARM template

download package

NuGet package

PowerShell scripts

PowerShell task

SQL database

TDD environment

UpdateAzureSQL.ps1 file

variables

YAML configuration

ARM

attachment view

build summary page

business-critical applications

CI build

continuous deployment trigger

environments

functioning

key parts

NuGet package

NUnit test

NUnit/XUnit test

pre-deployment conditions

property page

Selenium driver

Selenium tests

TDD environment

UAT and production environment

database and data

execution

manual approval

master branch

production configuration

variables

Azure Pipelines

Azure Repos

Azure Resource Manager (ARM)

Azure Test Plans

B

Building code

structure

build and CI build

feature branch flows

master branch flows

types of build

using Azure Pipelines

CI build configuration

command-line arguments

dashboard

.NET Core solution

dotnet.exe restore output

private build script

stages

tests

variables defined

C

CIBuild function

Commit stage

Continuous delivery

Continuous integration (CI)

Continuous integration (CI) and deployment

configure Azure Pipelines pipeline

access GitHub repository

create build definition

GitHub commit

release, add artifact panel

release, pipeline name

release, production environment

release, template selection

create Azure DevOps organization

examine Azure Pipelines pipeline

build definition

release pipeline

GitHub repository option

remove local Git

D, E

DataConfigurationStub()

Defect removal efficiency (DRE)

implementation

full-system tests

inspections

integration test

static analysis

unit test

inspections

high-level items

pull request code

measurable DevOps process

static analysis

techniques

inspections

static analysis

testing

full-system tests

integration tests

manual

unit tests

Deployment pipeline

Azure

SeeAzure pipeline, deployment

data changes

administrative data

configuration data

schema data

types

user data

environment

production

TDD

types

UAT

principles

runtime architecture

logical

physical

spectrum

types

validation steps

DevOps architecture

application runtime

CI Build

development view

logical structure

logical view

manual test environment

methodology

amplify feedback loops

continual experimentation

system thinking

package management

physical view

private build

problems

explosive growth

reference implementation

process view

production environment

production monitoring

scenarios

solution structure

TDD environment

tools

version control

DevOps-centered application

Onion architecture

integrating DevOps assets

implementing in .NET core

F, G, H

Full-system tests

I, J, K, L

Integration tests

M

Monitor and debug

alerts

Application Insights

debugging

logging

log streaming

overview panel

self-service tools

N

.NET software, in Azure

observability

Application Insights

architectural model

controller action

Instrumentation Key

JSON substitution

principles

release annotation task

release marker

TelemetrySink class

telemetry types

testability

NuGet

O

Onion DevOps Architecture

P, Q

Pack function

Professional DevOps environment

DORA State

removing ambiguity

tools

Azure subscription

runtime environment

services

Visual studio 2019

R, S

Release candidate packages

Azure artifacts workflow

components

deployment configuration

Git repository

NuGet packages, CIBuild function

NuGet packages, Pack function

NuGet packages, PowerShell function

bounds of

rules

sequence of events

T

Team Foundation Version Control (TFVC)

Test-driven development (TDD)

Tracking code

Azure Repos

Azure Repos configuration

choose branching pattern

GitHub

Git repositories

applications

relationship rules

structure

versioning

Tracking work

Azure Boards, branch

change process template

creating pull request

customize state

GitHub connections

integration

linking commits

states, in software development project

work item types

U, V, W, X, Y, Z

Unit tests

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Back Matter

Create new playlist

Sign In

Sign Up

Index

A

B

C

D, E

F, G, H

I, J, K, L

M

N

O

P, Q

R, S

T

U, V, W, X, Y, Z

Table of Contents for
Back Matter