Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

24.2. Separating the Components

During testing and even live service, you're required to deploy updated components. Even if this activity is fully automated, it needs to be verified, which can take time. Verification could involve a combination of manual checks as well as running sample transactions through the system (which would need to be cleared out following the verification tests).

In testing, it is not unusual to deploy a patch or a hot fix to an environment. An issue might arise that needs to be turned around quickly, so instead of deploying a full code release, you deploy a discrete subset of components or libraries. Although this is also true in production sometimes, the operations and service delivery teams will generally want all production servers and environments to be in-sync. For example, consider a simple change in the SystemFramework library. This library would need to be deployed to all the servers across the estate, including the disaster recovery site. If it is not, there is the chance that Version 1 could reside on some servers while Version 2 could reside on another server, as shown in Figure 24-1.

Figure 24.1. Figure 24-1

The operations and service delivery teams are not usually keen to deploy single hot fixes and libraries like this unless it's absolutely necessary for emergency purposes. They'd much rather deploy a full release, knowing that all the ...