🔒 Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

CI/CD is usually sold as a promise of speed.

• “Deploy faster.”

• “Release more often.”

• “Ship ten times a day.”

And yet, most teams I work with deploy more frequently than ever — and still dread it.

Deployments are green, pipelines are automated, dashboards look healthy, but…

• Slack explodes after releases.

• People hover over rollback buttons.

• The customers are complaining.

That’s the paradox.

CI/CD didn’t make teams feel safer…

It made them move faster while staying afraid.

The truth is - the team thought that they were practicing CI/CD, but they actually weren’t. They had a pipeline (they thought that means CI/CD), but didn’t have adequate automated tests, instead relying on Manual QA.

If they we truly practicing CI/CD, they would have both safety & speed.

The Lie We Were Sold

Speed is easy to sell.

Speed has metrics.
Speed has charts.
Speed looks good in talks and blog posts.

So CI/CD got framed as a productivity tool:

“Look how often we deploy.”

But deploying often is not the goal.

Deploying without fear is.

Speed without safety just means you’re reaching failure sooner.

What CI/CD Is Actually Optimizing For

At its core, CI/CD optimizes for risk reduction.

Every practice that matters in CI/CD points to the same outcome:

• smaller failures

• earlier feedback

• faster recovery

• less human panic

CI/CD is a risk-management system disguised as automation.

When it works, deployments stop being events.
They become background noise.

Not because nothing can go wrong —
but because when something does, you already know how it will go wrong, where, and how to undo it.

The Four Safety Nets of Real CI/CD

Read more

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code.

Subscribe now

99% developers do NOT know what CI is.

They think that CI means building a Pipeline.

However, those developers adopt Feature Branching & have no Tests.

They don’t know that Feature Branching is NOT compatible with CI.

They also don’t know that Tests are a must-have for CI.

CI requires at least daily integration.

The only way to satisfy CI is with:

• (A) Trunk Based Development, whereby we just have the "main", we don't have any branches

• (B) Short-lived branches, where branch lifetime <=1 day

The following does NOT satisfy CI:

• (C) Long-lived branches, where branch lifetime > 1 day

Trunk Based Development (TBD)

Trunk Based Development is a branching strategy where developers integrate their changes into a single shared branch (the trunk) at least once a day (ideally, multiple times per day). The goal is to keep integration simple, reduce merge conflicts, and ensure that the product is always in a releasable state.

✅ Satisfies minimal conditions for Continuous Integration (CI)

(A) No branches

• All changes are integrated directly into the trunk

(B) Short-lived branches (≤ 1 day)

• Changes are integrated into branches, branches are re-integrated into the trunk daily, branches are removed after merge

Feature Branching

Feature Branching is a branching strategy where developers create a separate branch for each feature, bug fix or refactoring. These branches often exist for multiple days (sometimes weeks) before being merged back into the main branch. This can create long feedback cycles, painful merges, and delays in integration.

⚠️ Does NOT satisfy the minimal conditions for Continuous Integration (CI)

(C) Long-lived branches (> 1 day)

• Changes are integrated into branches, branches are re-integrated into the trunk over longer timeframes, or branches remain indefinitely

Leave a comment

📅 Join me at the FREE live event Stop Breaking Production: ATDD in Legacy Code (Sep 24 at 5:00 PM CET)

🔒Hello, this is Valentina with a premium issue of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. This article is part of the TDD in Legacy Code series.

Subscribe now

The only way to be able to deliver safely and quickly into production is through Continuous Delivery (Jez Humble):

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand.

We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes on a daily basis. We thus completely eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes.

The foundation of Continuous Delivery is the Pipeline.

Pipeline

The Pipeline is composed of at least 3 stages:

1. Commit Stage - automatic verification whether Components work (in isolation)

2. Acceptance Stage - automatic verification whether the System works (as a whole)

3. Release Stages:

   1. QA Stage - QA verification whether the System works

   2. UAT Stage - business validation whether System meets business needs

   3. Staging Stage - final validation in a production-like environment

   4. Production Stage - releasing to the End User

It should be noted that the Acceptance Stage is responsible for the automated verification of functional requirements only. To verify non-functional requirements, we need additional stages, e.g.:

• Performance Stage - verify whether the System meets performance requirements

• Security Stage - verify whether the System meets security requirements

Note: There are no limitations regarding this list of Stages. Please structure it based on non-functional requirements.

Commit Stage

The goal of the Commit Stage is to verify that Components work in isolation & publish their Artifacts.

The Commit Stage is triggered when developers push changes to the Version Control System.

For each Component, the following are the key steps in the Commit Stage:

1. Checkout the Component code

2. Compile the Component code

3. Verify that the Component works correctly (in isolation)

   1. Run Unit Tests

   2. Run Narrow Integration Tests

   3. Run Component Tests

   4. Run Contract Provider Verification Tests

4. Verify that the Component’s code is maintainable, secure, etc.

   1. Run Linter

   2. Run Static Code Analysis

5. Publish Component’s Artifact to the Artifact Repository

   1. Build Artifact

   2. Publish Artifact

Read more

Subscribe now

In the previous article, Modern Pipeline - Acceptance Stage, we verified whether our System works correctly, by running automated System Level Tests. Within the Acceptance Stage, it deployed the System to the Acceptance Environment, ran Health Checks, Smoke Tests, Acceptance Tests, External System Contract Tests, and E2E Tests.

Since the Acceptance Stage assured us that our System satisfies Acceptance Criteria, i.e. that it works correctly from End User facing perspective, we’re now ready to make the System available to humans, most importantly:

• Release the System to QA Environment, so that QA Engineers can test it

• Release the System to Production Environment, so that Users can use it

Note: We’re not limited to just the QA Environment. We’ll see some additional environments below.

Note II: The Acceptance Stage covers only functional testing, but it does not cover non-functional testing. You can consider having additional stages, e.g. Load Test Stage, Stress Test Stage, Soak Test Stage, Security Test Stage, Resilience Test Stage, etc. To summarize, to perform automated non-functional testing, you need to add additional stages to the Pipeline.

QA Stage

In the Acceptance Stage, we had automatic verification that the System works correctly, that it satisfies functional requirements.

For a version of the System that passed the Acceptance Stage, we need to make it available for humans for both functional and non-functional testing, involving:

• Exploratory Testing

• Usability Testing (UX Testing)

• Visual Testing (Cross-browser & Cross-device UI Testing)

• Exploratory Security Testing

Note: QA Engineer should NOT perform Manual Regression Testing! Automated Regression Testing was already executed by the Acceptance Stage. It's important to note that here we’re referring to Functional Regression Testing, since that should be automated not done manually.

Read more

🔒 Welcome to the premium Optivem Journal. I’ll help you apply TDD to escape the nightmare of Legacy Code. Join our paid community of 160+ senior engineers & leaders for support on your TDD journey, plus instant access to group chat and live Q&As:

Subscribe now

It’s not enough for Components to work in isolation. We need assurance that the whole System works together. In the previous article, Modern Pipeline - Commit Stage, we showed how we can be sure that our Components work in isolation (through Component Level Tests & Unit Level Tests). Now it’s time to find out how we can be sure that the whole System (all the Components working together) works correctly, i.e., are the business requirements satisfied?

Acceptance Stage - Health Checks & Smoke Tests

At the simplest level, we need to automatically deploy the System & run automated Health Checks & Smoke Tests. This tells us that the System is up-and-running:

Note: Within the “Release System“ step, we need to “Configure Environment“. As part of that configuration, we need to configure the connection strings to External Systems to point to External System Test Instances.

Read more

🔒 Welcome to the premium Optivem Journal. I’ll help you apply TDD to escape the nightmare of Legacy Code. Join our paid community of 160+ senior engineers & leaders for support on your TDD journey, plus instant access to group chat and live Q&As:

Subscribe now

The goal of the Pipeline is ultimately to release software quickly and safely into a given environment. To achieve this, a necessary (but not sufficient) step is to deploy the System to an Environment automatically.

Components

The automatic deployment of a System necessitates the automated deployment of Its Component(s).

A System is comprised of one or more Components. Components might be the following:

• MVC App

• Frontend, Backend

• Frontend, Microservice #1, Microservice #2, Microservice #3, etc.

Note: Instead of Frontend, or additionally, there might be Mobile, Desktop, Console, etc.

Artifacts

Automated deployment of a Component necessitates that we automate the publishing of the Component Artifact, so that we can deploy it.

Artifacts might be Docker Images, or JAR/WAR files (Java apps), DLL/EXE (.NET apps), Node.js bundles, NuGet packages. Artifact Repositories might be Docker Hub, JFrog Artifactory, AWS CodeArtifact, Azure Artifacts, Google Artifact Repository, etc…

(System) Commit Stage

The first step of automating Component deployment is to build and publish its Artifact automatically. This’s the purpose of the Commit Stage - to publish the Component Artifacts, so that we can deploy those Component Artifacts in subsequent stages (Acceptance Stage & Release Stage).

From a System perspective, here’s the (System) Commit Stage. It’s comprised of Component Commit Stages that run in parallel. Each Component Commit Stage publishes that Component’s Artifact to the Artifact Repository.

Read more

Subscribe now

Congratulations! You’ve now completed your Pipeline setup (TDD in Legacy Code series), which is an important prerequisite before we get started with TDD. Let’s recap what we’ve built up to now:

• ✅ Commit Stage

• ✅ Release Stage

• ✅ Acceptance Stage

Why did we build a Pipeline before starting TDD?

Legacy Code often lacks a Pipeline, and instead, the delivery process is manual—manual releases and manual testing.

What would happen if a team attempted to start TDD on a Legacy Project - but without a Pipeline?

• Problem 1. Inconsistent Component Level Test results. Component Level tests include Unit Tests, Narrow Integration Tests, Component Tests & Contract Tests. If there is no Pipeline, a developer might write these tests, and get them to pass locally (as part of the GREEN step in TDD), and commit the code, but then when another developer pulls the source code, it fails on their machine! So on one developer’s machine the tests pass, yet on another developer’s machine it fails! (Of course, there is a deeper issue there with the tests, but it's now blocking the team because there's no Pipeline that detected as issue with the test)

• Problem 2. Can’t effectively run System Level Tests. System Level tests include Acceptance Tests & Contract Tests, Smoke Tests & E2E Tests. When there’s no Pipeline, to run any automated system tests, you first need to manually deploy the System. This is time-consuming and error-prone, hence we’re limited how frequently we can run those tests. And even when we run them, if there’s an error, we don’t know if it’s a deployment issue or something else.

We needed a Build Server so that tests can be verified independently of the developer’s local machine (solving Problem 1) and that we can run slower tests (solving Problem 2). We needed a Pipeline to get feedback if any tests are red on the Build Server, even though they might be green on the Local Machine (solving Problem 1), and that we could automate deployment to enable System Level (solving Problem 2).

Thus, before introducing any tests (and TDD), we must ensure we have a Pipeline. A Pipeline is central to Continuous Delivery, enabling us to test our release candidates to ensure that we can safely and quickly release to production.

Pipeline Architecture to support TDD

We had set the following Pipeline Architecture:

• ✅ Repositories

• ✅ Environments

• ✅ Pipeline

Let’s summarize what we’ve learnt up to now:

1. Repositories

Component Repositories

We’ve set up Component Repositories:

• Frontend Repository

• Microservice #1 Repository

• Microservice #2 Repository

• Microservice #3 Repository

In each Component Repository, we added test placeholders for Component Level Tests:

• Unit Tests

• Narrow Integration Tests

• Component Tests

• Contract Tests

System Level Test Repository

Furthermore, we setup a repository for System Level testing:

• System Test Repository

In the System Test Repository, we added test placeholders for System Level Tests:

• Acceptance Tests

• External System Contract Tests

• Smoke Tests

• E2E Tests

2. Environments

Automated Test Environments

• Acceptance Environment - for executing Acceptance Tests

• E2E Environment - for executing External System Contract Tests & E2E Tests

• Performance Environment - for executing Performance Tests

• Security Environment - for executing Security Tests

Note: We covered Acceptance Environment and E2E Environment, which are focused on automated functional testing. Furthermore, you can have environments for non-functional tests, e.g. Performance Environment and Security Environment.

Manual Test Environments

• UAT Environment - for executing Manual QA Tests

Release Environments

• Staging Environment

• Production Environment

3. Pipeline

Pipeline Stages

The Pipeline has these Stages:

1. Commit Stage - running Component Level Tests (Unit Tests, Narrow Integration Tests, Component Tests, Contract Tests) and publishing Docker Images

2. Acceptance Stage - deploying Docker Images to Acceptance Environment and running Smoke Tests & Acceptance Tests; deploying Docker Images to E2E Environment and running Smoke Tests, External System Contract Tests & E2E Tests

3. UAT Stage - deploying Docker Images to UAT Environment, running Smoke Tests, so that then QA Engineers can do Manual QA Testing

4. Performance Stage - deploying Docker Images to Performance Environment, running Smoke Tests, running Performance Tests

5. Security Stage - deploying Docker Images to Security Environment, running Smoke Tests, running Security Tests

6. Staging Stage - deploying Docker Images to Staging Environment, running Smoke Tests

7. Production Stage - deploying Docker Images to Production Environment, running Smoke Tests

Note: We didn’t cover the Performance Stage, Security Stage, or Staging Stage; you can optionally add them if you need them.

Pipeline Dashboard

Note: You can also add Performance Stage, Security Stage, Staging Stage between the UAT Stage and Production Stage.

What’s Next?

As part of the Pipeline phase, we’ve completed:

• Commit Stage

• Release Stage

• Acceptance Stage

I know that Pipeline setup was not the most exciting part, but now we’re ready to get to the fun part! In our upcoming articles, we’ll be learning about:

• Testable Architecture: How do we make Legacy Code architecture testable so that it can support testing?

• Test Last Development: How do we effectively write tests retroactively in a Test-Last approach?

• Test Driven Development: Finally, how do we switch to Test-Driven Development?

You can access the full series here: 👇👇👇

Subscribe now

Legacy Code has Manual Acceptance Testing

In Legacy Code, QA Engineers perform Manual Acceptance Testing (Manual E2E Testing), commonly referred to as UAT testing, before releasing the system to Production. This is time-consuming and error-prone, and results in delayed releases.

Can’t do ATDD with Manual Acceptance Tests

We can’t practice ATDD with Manual Acceptance Tests because they are time-consuming, hence were can’t run them often. Furthermore, they are error-prone, so we can’t trust their results.

We need an Acceptance Stage to support ATDD

In order to practice ATDD, we need to start development of any new feature with Automated Acceptance Tests, and to be able to regularly run those tests. We can run these Acceptance Tests to know when we’ve satisfied the User Story Acceptance Criteria. Furthermore, we use these tests in the future for regression testing at the system level. By eliminating manual acceptance testing, we gain both safety and speed, and enable QA Engineers to do Exploratory Testing.

Previously, we set up the Release Stage, which deployed Docker Images to environments, so that the QA Engineer could do Manual Acceptance Testing. In this article, we will be looking at the Acceptance Stage - running (Automated) Acceptance Tests, External System Contract Tests and E2E Tests.

Here are the steps for adding the Acceptance Stage to Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

Legacy Code often has Manual Releases

In Legacy Code, the release process might be manual. This means there’s a written procedure that documents all the deployment steps - for example, manually setting up the environment, manually deploying the artifacts to an environment, manually running database migration scripts, and manually opening up the app after the deployment to make sure that it’s up and running.

Manual Releases are inconvenient for ATDD

The problem with manual releases is that they are time-consuming and error-prone. Manual Releases are not reliable. For example, we can deploy to the UAT Environment, and it’s fine, but if we make a small error in the deployment to the Production Environment, the system doesn’t work for the end users.

Furthermore, Manual Releases would make it inconvenient for us to practice ATDD. Since we may need to run Acceptance Tests on the pipeline multiple times a day, this isn’t practical if the releases are manual.

We should have a Release Stage to support ATDD

Before we start with ATDD, we need to ensure that we set up an automated release process. That’s why we need a Release Stage in our Pipeline. The Release Stage automates environment configuration and deployment of our system environments, as well as basic smoke testing of the system. By eliminating manual activities in the deployment process, we gain both safety and speed, eliminate deployment errors, and perform deployment fast anytime.

Previously, we set up the Commit Stage, which resulted in publishing the Docker Images for the Docker Registry. In this article, we will be looking at the Release Stage - deploying the Docker Images to environments.

Here are the steps for adding the Release Stage to Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more

Subscribe now

Legacy Code: the build is (often) broken

The developer was manually compiling the code (perhaps running a few tests, if any). It seemed to be working, so they deployed it to a server.

A few minutes later, a teammate pulled the latest source code, ran compilation (and very few tests, if any), and said the build didn’t work.

The first developer then exclaimed:

“But it works on my machine!“

In Legacy Code projects, there might not be any centralized Build Server, and the build process might be manual. The development team might compile the code locally and produce artifacts that they would later use for manual deployment.

TDD is ineffective if you have Manual Builds

The problem is, that when the build process is manual, it is error-prone and time-consuming. Furthermore, the person who manually builds the system might not even be running any tests, if any. We have the problem of “it works on my machine”, whereby the tests (if any) might be passing on that machine but not generally working.

Therefore, even if a team tried to do TDD, their tests could be all green locally on their machine, but those same tests could fail on other machines, and the software itself might not be working. Furthermore, the developer who manually builds the system might forget to run the tests and just compile the code.

Consequently, if you try to practice TDD but you have Manual Builds, then TDD is only partially effective for you.

We need Build Automation for effective TDD

That’s why we need to automate the build process - using the Commit Stage. This ensures that code compilation and test execution are done on a separate independent machine. This prevents the case that compilation and tests “work on my machine“, and thus prevents faulty builds.

We automated the build using the Commit Stage. The Commit Stage is the first stage in the Pipeline—it compiles code, runs developer-facing technically focused tests, and runs static code analysis. Assuming all that passed, the Commit Stage generates Artifacts and stores them in the Artifact Repository. Legacy Projects may not have a Commit Stage at all, or they might be poorly designed, so that’s what we have to fix to enable the execution of technical tests.

Furthermore, having a Commit Stage within the Pipeline is a prerequisite for Continuous Integration (CI), irrespective of TDD.

Therefore, in Legacy Projects, don’t jump to TDD unless you have setup Build Automation first. That’s why, in the TDD in Legacy Code Transformation, we start with the Pipeline Commit Stage:

Here are the steps for adding the Commit Stage to Legacy Code. You’ll get tasks to implement in your GitHub Sandbox Project. ⬇️⬇️⬇️

Read more