Build & Unit Testing
Development teams regularly merge code into a shared code base and require an environment to build and test integrated code. This is often referred to as a system integration test environment, or SIT. The SIT environment is completely unstable. If a team is using a continuous delivery approach to software development, the SIT environment may be built and tested several times a day.Automated Acceptance Testing
An environment that automatically runs test cases against a build. These are often regression tests that confirm that existing functionality hasn't been broken by a build. It is also common to develop and deploy new automated test cases as part of a development cycle such as a sprint.User Acceptance Testing
User acceptance testing, or UAT, is the process a business unit uses to accept software. As the term suggests, this is a test from the user perspective and is often a manual check. Detected variances are documented as defects. User acceptance testing is a stable environment with builds that are coordinated between development and testing teams including communication of what defects are fixed in a build. It is common for UAT to be built a few times a week.Operational Acceptance Testing
Operational acceptance testing, or OAT, is the process of confirming that a release is resilient and supportable. For example, confirming that it can handle the load of production. This may be both automated and manual. It is common for operational acceptance testing environments to be kept quite stable such that only code that is a candidate for production is ever released to OAT. It is also common to run OAT in the UAT environment as a separate phase of testing.Security Testing
Security testing is validation that a software release is reasonably secure. This is performed by a team of information security specialists using techniques such as vulnerability assessments and penetration tests. This may have its own environment or may be run in a UAT or production staging environment.Production
Production is any environment that is used by customers. This is typically the most stable environment in the pipeline as many builds may be accumulated into one production release as part of a release management strategy. As an example, SIT may be built 3 times a day but production deployments may occur less than once a month.Deployment Pipeline Process
Development teams that continuously integrate their code as part of a continuous delivery process may merge their code into a shared mainline several times a day using a version control tool. This is typically automatically deployed to a unit testing environment with both automatic and manual tests to confirm the build is as expected. When unit testing passes the code proceeds to an automated acceptance testing environment with automated regression tests that test all existing test cases that can be automated. This process may occur several times a day with fixes being applied when tests fail and the process repeated.
| Overview: Deployment Pipeline | ||
Type | ||
Definition | A series of environments that are used for different levels of software testing and validation. | |
Related Concepts | ||
