Parallel Work Is Complicated

There are teams working on different new features. However, the parallel work is complicated: the software structure just doesn’t really support it. The individual modules are not separated well enough and have too many interdependencies. As everything can only be deployed together, the entire deployment monolith has to be tested. The deployment and testing phases are a bottleneck. Whenever a team has a problem in the deployment pipeline, all other teams have to wait until the problem has been fixed and the change has been successfully deployed. Also, access to the continuous delivery pipeline has to be coordinated. Only one team can be doing testing and deployment at a time. There has to be coordination between the teams to determine the order in which teams will bring their changes into production.

Bottleneck During Testing

In addition to deployment, tests also have to be coordinated. When the deployment monolith runs an integration test, only the changes made by one team are allowed to be contained in the test. There were attempts to test several changes at once. This meant it was very hard to discern the origin of errors and led to error analyses that were long and complex.

One integration test requires approximately one hour. About six integration tests are feasible per working day, because errors have to be fixed and the environment has to be set up again for the next test. If there are ten teams, one team can bring one change into production every two days, on average. However, often a team also has to do error analysis, which lengthens integration. For that reason, some teams use feature branches in order to separate themselves from integration; they perform their changes on a separate branch in the version control system. Integrating these changes into the main branch later on often causes problems; changes are erroneously removed upon merging, or the software suddenly contains errors that are caused by the separated development process and that only show up after integration. These errors can only be eliminated in lengthy processes after integration.

Consequently, the teams slow each other down due to the testing (see Figure 2.1). Although each team develops its own modules, they all work on the same code base so that they impede each other. As a consequence of the shared continuous delivery pipeline and the ensuing need for coordination, the teams are unable to work either independently of each other or in parallel.

Teams Slow Each Other Down due to the Deployment Monolith

Figure 2.1 Teams Slow Each Other Down due to the Deployment Monolith

< Prev   CONTENTS   Source   Next >