Wrapping up – a complete example

So far, we have covered a lot of information at a cursory level.

To make it clearer, let's have a look at what happens to a concrete change as it propagates through the systems, using an example:

• The development team has been given the responsibility of developing a change to the organization's system. The change revolves around adding new roles to the authentication system. This seemingly simple task is hard in reality because many different systems will be affected by the change.
• To make life easier, it is decided that the change will be broken down into several smaller changes, which will be tested independently and mostly automatically by automated regression tests.
• The first change, the addition of a new role to the authentication system, is developed locally on developer machines and given best-effort local testing. To really know whether it works, the developer needs access to systems not available in their local environment—in this case, a Lightweight Directory Access Protocol (LDAP) server containing user information and roles.
• If test-driven development is used, a failing test is written before any actual code is written. After the failing test is written, new code that makes the test pass is written.
• The developer checks the change to the organization's revision control system, a Git repository.
• The build server picks up the change and initiates the build process. After unit testing, the change is deemed fit enough to be deployed to the binary repository, which is a Nexus installation.
• The configuration management system, Puppet, notices that there is a new version of the authentication component available. The integration test server is described as requiring the latest version to be installed, so Puppet goes ahead and installs the new component.
• The installation of the new component now triggers automated regression tests. When these have been finished successfully, manual tests by the quality assurance team commence.
• The quality assurance team gives the change its seal of approval. The change moves on to the staging server, where final acceptance testing commences.
• After the acceptance test phase is completed, the staging server is swapped into production, and the production server becomes the new staging server. This last step is managed by the organization's load-balancing server.

The process is then repeated as necessary. As you can see, there is a lot going on!