The demonstrated examples cover general Java build piplines which are, of course, applicable to Java EE as well. In fact, using Java Enterprise highly supports productive development pipelines. Fast builds and therefore fast developer feedback is crucial to effective Continuous Delivery workflows.
Zero-dependency applications, especially when packaged in containers, leverage these principles as we have seen in Chapter 4, Lightweight Java EE. The enterprise application in the packaged artifact or the container layer, respectively, only contains the business logic that was developed against the API. The application container provides the implementation.
The Continuous Delivery pipeline benefits from zero-dependency applications, since the involved build and distribution steps only require short execution and transmission times, respectively. Artifact builds as well as container builds run as fast as they can get, with only copying what's absolutely necessary. In the same way, publishing and deploying artifacts, as well as container layers, only contain the required business concerns, to minimize transmission time. This leads to fast turnaround and fast feedback.
Having effective pipelines is crucial to implementing a Continuous Delivery culture in the development team. Engineers are motivated to check in early and often, since the pipeline runs fast, provides fast feedback, and increases the confidence that the software quality is met.
As mentioned earlier, build times should not take more than a few seconds. Build pipeline executions, including end-to-end tests, should not take more than a few minutes, ideally even faster.
Putting effort into making builds and pipelines run faster should be a goal of the engineering team. During a workday, developers often build and check in the project. Every check-in results in a Continuous Delivery build that is a potential candidate for production deployment. If this overall process takes just, for example, 1 minute longer, all developers in the team wait 1 minute longer, every time they build the software. One can imagine that this delay adds up to a big number over time. Developers are tempted to check in less often if they have to wait for their result.
Improving the stability and performance of the pipeline, therefore, is a long-term investment in the team's productivity. Tests and steps that provide quick, helpful feedback by breaking the build faster in case of errors should run as early as possible. If some end-to-end tests run inevitably longer in time, due to the nature of the project and the tests, they can be defined in separate downstream pipelines steps, to not delay feedback of earlier verification. Steps that can run in parallel, such as static code analyses, should do so, to speed up the overall execution. Using the modern approaches of Java EE development greatly supports crafting productive build pipelines.
Still, technology is only one aspect of effective Continuous Delivery. Introducing Continuous Delivery has an even bigger impact on the development team's culture. Let's have a closer look into this.