Sometimes, paring down your test suite by removing tests with low value or with indeterminate conclusions is the smartest way to maintain the speed required by a heavily used pipelines. When making these significant decisions, make sure you understand and document the trade-offs you are making. Consult with team members and stakeholders to align the team’s assumptions about what the test suite is responsible for and what the primary areas of focus should be.
Since the CI/CD system has complete access to your codebase and credentials to deploy in various environments, it is essential to secure it to safeguard internal data and guarantee the integrity of your site or product. CI/CD systems should be deployed to internal, protected networks, unexposed to outside parties.
Every change to your production environment goes through your pipeline. The CI/CD pipeline should be the only mechanism by which code enters the production environment
Significant differences between staging and production can allow problematic changes to be released that were never observed to be faulty in testing. The more differences between your live environment and the testing environment, the less your tests will measure how the code will perform when released.Some organizations use blue-green deployments to swap production traffic between two nearly identical environments that alternate between being designated production and staging
If your software requires a building, packaging, or bundling step, that step should be executed only once and the resulting output should be reused throughout the entire pipeline. To avoid this problem, CI systems should include a build process as the first step in the pipeline that creates and packages the software in a clean environment. The resulting artifact should be versioned and uploaded to an artifact storage system to be pulled down by subsequent stages of the pipeline, ensuring that the build does not change as it progresses through the system
This strategy has a number of benefits that can help keep your CI/CD process healthy. It encourages you to understand the performance impact of individual tests, allows you to complete most of your tests early, and increases the likelihood of fast failures, which means that problematic changes can be reverted or fixed before blocking other members’ work.
One of the main principles of CI/CD is to integrate changes into the primary shared repository early and often. This helps avoid costly integration problems down the line when multiple developers attempt to merge large, divergent, and conflicting changes into the main branch of the repository in preparation for release. Typically, CI/CD systems are set to monitor and test the changes committed to only one or a few branches. Most implementations suggest that developers commit directly to the main branch or merge changes from their local branches in at least once a day. Essentially, branches that are not being tracked by your CI/CD system contain untested code that should be regarded as a liability to your project’s success and momentum
developers should be encouraged to run as many tests locally prior to committing to the shared repository.
To help ensure that your tests run the same at various stages, it’s often a good idea to use clean, ephemeral testing environments when possible. Usually, this means running tests in containers to abstract differences between the host systems and to provide a standard API for hooking together components at various scales.
The basic concept behind blue-green deployment is that two sets of environments, each capable of serving your application in production, are maintained. These two environments should be nearly identical. By convention, these are referred to as the blue and the green environments. Only one of these environments is active and receiving production traffic at any one time. In front of the web endpoints for these environments (either web servers or load balancers), a router or other traffic directing mechanism pushes all production traffic to the currently active environment. When a new release is planned, it is deployed to the non-active environment. Once you have tested your deployment internally and have gained confidence in its robustness, you can release the new version quickly and easily by adjusting the routing mechanism. Basically, you flip the switch at the traffic directing layer so that all production traffic begins to move to your new software version. Dealing with Database Updates A better alternative is usually to share a single database system between the green and blue environments. The application code will be switchable using the blue-green release strategy, while the database itself will used by both environments. If we deploy a new release to staging that adds to or alters the database in a way that doesn’t work with the current production deployment, we will break our application. To prevent this from happening, it is often best to deploy your migrations separate from your code base deployments and in stages where necessary. This modified process is sometimes called blue-turquoise-green deployment. Basically, it hinges on deploying an intermediate version of your application code that can handle both the old and new versions of your database