Delivery Driven Development (DDD)

Introduction

The purpose of this article is to describe a new Development Methodology called "Delivery Driven Development" or DDD. This methodology is currently being used with great success across a large range of organisations.

Delivery Driven Development (DDD) does not replace existing methodologies such as Test Driven Development (TDD) or Agile, but rather supplements and enhances their effectiveness.

The purpose of this methodology is to elevate the importance of delivery so that it becomes more than a development afterthought. Instead, the delivery channel becomes the first consideration post the initial Analysis and Design phase of the SDLC.

By publishing this article, I hope to engage the community and invite constructive peer review.

Background

In the 90s and even into the early noughties, the types of delivery channels were often limited. There was no Github, Azure, or AWS and few examples of cloud hosting. Software was usually hosted on-prem with some examples of shared infrastructure. Furthermore, impediments like security have also increased as companies are becoming more security conscious.

Although a company may have had many clients, the variance in delivery channels and complexity in the delivery process was a lot less than it is now.

In the past, many companies have adopted TDD and depending on the project, either Waterfall or Agile Development methodologies. These practices have often been employed with varying levels of success.

Whether an accurate method of assessment or not, the yardstick often used to determine the success or failure of these practices was the delivery outcome.

This creates ambiguity in the process, as the delivery channel is not directly controlled by TDD, Waterfall, Agile or any other well known methodology.

Target Audience

As with most methodologies, this methodology won't be suitable for every company or project. In fact, unless you're deploying to many customers, each with different deployment channels and logic, the benefit of this methodology may not be immediately apparent.

For example, a software vendor where this is successfully being implemented has at least 100 customers. Each customer has at least 5 environments and 3 deployment targets within each environment. Some customers host the solution onprem and others host using shared infrastructure or in the cloud. Further more, each customer has varying levels of security in the form of hardware, policies and rules.

What are the Steps in Delivery Driven Development (DDD)?

DDD is made up of five steps to drive the Analysis, Design, Implementation, Testing and Delivery of a solution.

Channel Analysis

Channel Analysis is the "Where" step. It involves identifying the destination of deployment assets.

The word "Destination" is a very broad term and meant to be inclusive. For many companies, this step would include consideration for:

1. Nuget
2. MyGet
3. npm
4. Windows FileSystem
5. Windows Web App
6. Windows Service
7. Azure SQL
8. Azure Web App
9. Azure App Service
10. SqlServer
11. Octopus Deploy (destination for deployment packages)

Channel Design

Channel Design is the "How" step. It involves determining how deployment assets will be delivered.

The days of an MSI for deploying large, complex solutions to a cluster of target servers, services and repositories are nearing an end.

In most cases, the Build and Release process will remain largely the same across all projects. However, the Deploy process may vary based on a customers infrastructure, platform and security model. For many companies, this step would include consideration for:

• Target Environments, i.e., Dev, UAT, Training, Staging, Prod
• Target Machines
• Target Machine Role, e.g., Windows Server, Application Server, Database Server
• Load Balancer
• Disaster Recovery (DR) Plan
• Version of Windows, SQLServer and SharePoint
• Windows or Token based Authentication
• Firewall rules and Windows Group Policy
• In the case of Octopus Deploy, the type of Tentacle to be used. This may vary depending on the environment.

Channel Implementation

Channel Implementation is the "Doing" step. It can involve the configuration of one or more channels. This step is largely driven by the Channel Design step and available tooling.

Commonly used tools for establishing the deployment channel include Team Foundation Server (TFS) and Octopus Deploy. For many companies, this step would include consideration for:

• Working closely with customers to ensure target machines can communicate with the deployment server, e.g., Octopus Deploy and Chocolatey
• Setup of repositories, e.g., MyGet & npm
• Environment Configuration via a central configuration management portal, e.g., Octopus Deploy

Channel Testing

Channel Testing is the "Fixing" step. It involves end-to-end smoke testing of the deployment channel. It's expected that this step will identify any issues which may compromise a successful release. For many companies, this step would include consideration for:

• Service Accounts, e.g., Octopus Tentacle service account, Web Services account and Windows Services account
• Environment Configuration
• Permission to access and download from Chocolatey
• Permission to update the Registry
• Permission to create and configure IIS Web applications
• Permission to install Windows Services
• Permission to Configure MSDTC
• Permission to Create SQL Server Databases
• Permission to run un-signed PowerShell scripts
• Permission to Install and activate SharePoint Solution for SharePoint Site

Channel Delivery

Channel Delivery is the final but crucial step. It involves the actual deployment of a Release or Release Candidate (RC).

This step should also include a full smoke test of a release in the target environment before it's officially handed to the customer for User Acceptance Testing (UAT).

What is the Relationship between TDD, Agile Development and Delivery Driven Development (DDD)?

History

• 22^nd August, 2018: Initial version