91������

In the modern tech landscape, it is crucial to be able to quickly build and deploy code that you know will work. This is achieved through having a continuous integration and continuous delivery (CI/CD) pipeline that properly tests your application before deployment and monitoring it after deployment. In this series of articles on CI/CD, we are going to talk about how to test throughout the CI/CD pipeline, some CI/CD best practices, and we’ll conclude by waxing philosophical about CI/CD and providing some words of encouragement.

In order to truly know that your code is working, you must implement various kinds of testing throughout your deployment pipeline. When testing is a key component of your continuous integration and continuous delivery (CI/CD) implementation, you will be able to deliver with speed and reliability. When configured, your CI/CD pipeline will automatically build, test, and deploy your code when it is merged into a branch. However, even though your pipeline will have the major stages of build, test, and deploy, there is testing that happens throughout the pipeline. In this article, we will discuss what testing is available to you, what pipelines look like, and then discuss how to test throughout the pipeline.

What Kinds of Testing are Available Throughout the CI/CD Pipeline?

The types of tests you use, regardless of workload type (e.g., web app, container, backend application), are going to be largely the same. There will be special considerations for each language and platform and environment. Languages and platforms will use different tooling. Your environments will have different configurations, networks, and secrets. But the fundamental ideas will be the same.

Regardless of language or platform, you will need to test and those principles remain the same. Let’s run through some core types of testing:

• Unit Testing: A unit test, as the name implies, tests an individual unit within your code: a function, module, or set of processes. By testing this way, you’ll be able to prove that each portion of the code is functioning correctly.
  ��
• Integration Testing: Once you’ve proven that each unit of your code is functioning properly, you can then do integration testing to make sure that each unit is working properly with each other.
  ��
• Performance Testing: This kind of testing is used to determine if your systems will be responsive and stable.

There are a number of tests you can perform to determine if your system is performant.��Let’s cover a few of them:

• Load Testing: Can your system handle the expected load? What about higher loads?
  ��
• Stress Testing: Now that your system can handle high loads, let’s push the limits and see what it can really handle.
  ��
• Spike Testing: This type of testing determines if the system can handle large and quick spikes in load.
  ��
• Configuration Testing: What happens to the system if we start messing around with its configuration? How does this affect the performance?
  ��
• Security Testing: Security testing checks for flaws in your project’s security by checking for risks and vulnerabilities.
  ��
• Chaos Testing: This is an extreme form of testing that is used in production environments. Chaos testing will kill nodes, disable ports, and make other heinous configuration changes. The purpose of this chaos is to test the resiliency of your system and, to see if things can self-heal properly. A; and all of this testing is done during business hours so your developers can fix things while they’re at work, not at three in the morning.

Testing Throughout the CI/CD Pipeline

You might be asking yourself: What should I be testing for? How and when should I be doing it? Do I need to test every single line of code? We’ve run through some core testing methodologies, so now let’s run through a basic CI/CD pipeline and talk about when we should be applying those tests. First, let’s summarize the basic stages of a CI/CD pipeline and then get more specific:

• Build: Depending on your specific application and environment configuration, your code is compiled, dependencies are pulled in and the application is built into a deployable artifact. Docker images may be built at this time.
  ��
• Test: Automated tests are run against your code. These tests are written to ensure not only that your code is written correctly, but that it’s doing what you think it should be doing.
  ��
• Deploy: Your code is deployed to your various environments. This can be fully automated. More often, the code is automatically deployed to the lower environments for testing. Then, in production, there may be needed approvals, a scheduled deployment, or, if all tests pass, an automated deployment.

Build

Your CI/CD pipeline always begins with a version control system. When your code is pushed to the remote repository, it should be automatically built. This could be building a Docker image, compiling code, running through an interpreted language. Even though this stage is going to look different for various types of applications, the core principle remains the same: the successful compilation or interpretation of your code is a test unto itself.

Test

Beyond that, you need to validate that your code is doing what you think it should be doing. This is where unit testing and integration testing come into play. Spend some serious time here and make sure that the results you’re getting are what you expect. Do you need to test for every single line of code? Absolutely not. In fact, having 100% code coverage is a fundamentally flawed idea because it works under the assertion that all of your tests are good. We are interested in testing for the right situations which will probably not be every line of code. Additionally, if your tests are too simple or too general, your functions can change in significant ways and the tests will still pass (remember, 1/1=1, but so does 1*1). Every test needs to be meaningful and serve a purpose.

Although your code is not yet deployed anywhere, there is some performance testing you can be doing now. Check for optimization and efficiency. Perform security testing to make sure that the base code isn’t vulnerable. Run through some configuration testing to make sure that your system is robust.

Do your tests need to vary based on the environment? Probably not, unless there are special or obvious caveats. But this is the exception, not the rule. Any differences between environments should be extracted into an environment configuration set and tested for.

Deploy

Once your code is merged into your main branch, it is ready for deployment to your various environments so that it can be tested, vetted, and ultimately proven worthy of production deployment. In this section we will discuss when to tag, merge, and release code. We will also briefly cover different deployment techniques.

When should you tag and release your code? Like all IT questions, it depends. If you’re using trunk-based development, all of your code will be merged into the main branch. When you are ready for a release, tag the main branch and run that tag through your testing environments before deploying to production. But how often should these releases happen? Again, that depends. For internal services, you can usually release more often. For critical and public systems, a more judicious approach may be warranted, perhaps only releasing on certain days or after certain times. But if your deployment methodology allows it, you can easily roll back to a known safe version which will allow you to deploy more frequently and with more confidence.

5 CI/CD Pipeline Deployment Metholodogies

There are a variety of deployment methodologies that you will need to consider. Let’s cover some of the more common ones include:

1. Recreate Strategy

The recreate strategy is one of the oldest deployment methods, where the previous version of the application is completely replaced by the new one. While simple to execute, it involves significant risk and downtime, making it impractical for most modern DevOps teams.

• The old environment is torn down before deploying the new version.
• Causes service interruptions and potential data loss if deployment fails.
• Considered outdated and primarily used as a historical example of early deployment methods.

2. Canary Deployments

A canary deployment introduces updates to a small subset of users or systems before releasing to the full environment. This controlled rollout allows teams to identify potential issues early, reducing risk while maintaining uptime.

• Deploy to a limited group of users or servers first.
• Monitor performance, stability, and user impact before full rollout.
• Expand deployment gradually as confidence increases.
• Minimizes the scope of production issues and ensures near-zero downtime.

3. Blue/Green Deployments

Blue/green deployment uses two identical environments to enable seamless releases and rollbacks. The new version is deployed to an idle environment and tested before traffic is switched over, ensuring no disruption to end users.

• Maintain two environments: one live (blue) and one idle (green).
• Deploy updates to the idle environment for testing and verification.
• Redirect traffic to the new environment once validated.
• Allows instant rollback to the previous environment if needed.

4. A/B Testing

A/B testing runs two production versions side by side to measure the effect of new features or changes. It’s often used to validate functionality, performance, or user experience improvements in real-world conditions before a complete rollout.

• Both environments (A and B) operate live simultaneously.
• Split user traffic to compare results and gather behavioral data.
• Analyze metrics like engagement, performance, and conversion rates.
• Enables data-driven decisions for product and feature optimization.

5. Feature Toggles

Feature toggles, also known as feature flags, give developers control over which features are active in production. This flexibility supports safer, faster releases and makes it easier to test or roll back individual functionality without redeploying code.

• Turn features on or off dynamically at runtime.
• Target specific users, regions, or environments with new releases.
• Simplify rollback by toggling features off instead of redeploying.
• Supports continuous delivery and controlled feature experimentation.

Ensure That Your CI/CD Pipeline Testing Is Dynamic

Testing throughout the pipeline not only validates your code — it accelerates delivery. By integrating automated tests at every stage, you can identify issues earlier, deploy with confidence, and maintain a steady flow of high-quality releases. Not every test needs to run in sequence. With the right strategy, teams can parallelize testing to save time and reduce bottlenecks.

91������ helps teams build smarter, more efficient pipelines through DevOps automation and intelligent testing. With the 91������ Salesforce DevOps platform, organizations can automate builds, tests, and deployments across environments — ensuring consistency, speed, and compliance.

‍

��