Hybrid builds make it possible to perform parts of a build on one or more platforms. This may be due to security requirements, proprietary software, resource allocation, tooling availability, compliance requirements, optimization strategy, or any multitude of other reasons.

For example, security concerns may prevent building sensitive code outside of private infrastructure. However, the cloud would be beneficial for platform testing. With hybrid builds, application code can be built on-premise and the artifact pushed to storage. From there, public infrastructure can be utilized for further testing and deployment.

Having a good design is paramount with any build, but hybrid builds require more planning due to the complexity of using more than one platform.

Isolating what parts of the build should be done on which platform is a good first step. The primary consideration for segregation is the level of interdependence. Each build will need to achieve a finish state that results in some complete action or artifact.

For example, a scenario where an application pipeline needs to start on-premises for security reasons but for optimization, the build process utilizes the public cloud to perform testing and deployment is a good use case. The build process starts the application build on-premises and produces an artifact as a docker image. The image is pushed into a private docker registry. From there, the public cloud is engaged to do integration, stress, and platform testing. If successful, the docker image is promoted for deployment.

Breaking down this process and identifying definite stages of transition is a good start. The other consideration is the trigger to start the testing process. For this example, there are multiple options for triggering the testing phase. The docker registry could be set to initiate upon a new push; a specific branch, tag, or comment could be used in conjunction with a Git repository; or triggering the pipeline directly using an API call at the end of the build phase.

There are many ways to accomplish hybrid builds. One such way is to use a pipeline tool, like Jenkins, on-premise. The tool can be configured to trigger on a push to a specific branch or branches. The result from that build could then further be processed in Azure DevOps.

Let's look at how this may be implemented. I've created a Jenkins file with some mock stages and steps to illustrate how a build might be configured. The Jenkins file will test the code, build the artifact, and then store the artifact. The last stage is to kick off any downstream automation.

In this case, an Azure pipeline's kickoff is being locked. Typically, any failure at any point would result in a terminated failed build. This pipeline is counting on that behavior. The downstream automation should never occur if an error exists prior to this stage. The trigger for the succeeding build is usually the most technical part of a hybrid build. Careful consideration must be given in order to execute the handoff properly. Here, the Azure DevOps API or the Azure CLI could be used to kick off the Azure pipeline's build.

Let's look at the Azure Pipelines file to round out this hybrid design. The Azure Pipelines file contains the trigger specification, the pool, and the testing stage with parallel capable jobs for integration and stress testing. Of course, this is only an example. Much more can be done here.

Lectures

• Introduction
• Build Tools
• Build Triggers
• Parallel Builds
• Conclusion