Development practices of creating feature branches that’s based on a snapshot in time of code functionality introduces challenges for applications made up of a number of microservices today. With each microservice having its own source code repository in Git and Jenkins job, how would you know the right version of the relevant microservice to use when testing the quality of each build? Compounded by the proliferation and complexity of the thousands of builds already in play, organizations lack the visibility and control to intelligently orchestrate for quality releases continuously. IT decision makers have been quite unanimous in their concerns over release complexities, as shared in a recent report.
Challenges when testing to feature branches
Take the typical example of a development team that’s been releasing software to a quarterly cadence. At the beginning of each release, the team gets a list of features that’s split among developers to work on. Each developer opens feature branches in the Git repository for every microservice that they have been tasked to modify. When development of a feature is complete, the developer merges the code to the “master” as seen in the development process below. Once release content is ready, the development team compiles for a new build release (including clean artifacts) and delivers changes made to higher environments (e.g. UAT, QA).
Example: “My Account” Git repositories and Branches
But for these same developers working from their CI build server and running integration tests, they are soon overwhelmed by all the microservices dependencies, with no visibility of the changes made in the release nor contextual insights for root cause analysis. Coordinating the process flows and tasks to scale complex scenarios in the development-integration environment is often error prone. Some of the microservices are deployed manually while others make use of different environments. With delays resulting from resource conflicts, developers struggle to run all the tests all of the time just to ensure releases are fully tested for quality – instead of being smart about what needs to be tested where in their projects.
Scale your Jenkins builds for continuous delivery
Teams need to intelligently orchestrate for efficiency and transparency in the release pipeline, where quality is embedded across every phase of the software development lifecycle. Broadcom Continuous Delivery Director (CDD) can help, with these new functionalities recently released.
- Frictionless CI/CD workflows
With the Jenkins integration, we have automated the process for developers to continue working from the familiarity of their CI build server through the use of a common unified setup for all the organization’s projects. No more having to consistently set and change settings manually for every Jenkins job. CDD analyses the Git repository to extract the application name/version for commit IDs and actual work items used in the build, before orchestrating to process flows and tasks in the CI/CD pipeline. One tool for all, there is no need for a dedicated setting for each application release when using CDD.
Image 1: Jenkins setting for unified build notification to CDD
- Reduce the complexity of releases
Using build notifications from the CI build server, CDD automatically adapts releases for feature branches without having to manually determine the right version of every microservice. With no interruption in workflows, developers start tracking and managing builds from a single source of truth that offers real time contextual insights and makes data driven decisions. CDD visualizes metrics to identify pipeline bottlenecks and inefficiencies, providing a release score that calculates the relative risk of deploying a new release to production.
Image 2: Calculate deployment risk of new releases with Release Scores
- Speed test cycles
When trying to orchestrate and streamline for quality releases, teams wrestle with bloated, inefficient test strategies today. CDD optimizes test resources by intelligently increasing test accuracy while at the same time automating manual steps in the pipeline that’s slowing down build velocity. With the use of Adaptive Testing, CDD prioritizes tests based on code changes in the current build to save hours of redundant tests which are not relevant to the new functionality. All the while identifying test defects as early as possible through the use of predictive insights, to find gaps in test plans and ensure maximum test coverage.
Image 3: Release Quality report with time saving from Adaptive Testing
Take the next steps
Start orchestrating efficiencies and transparency intelligently across your release pipeline. Join us for this interactive roadmap webinar with the CDD product management team as we discuss what it takes to enable an AI-powered continuous delivery pipeline. Get an exclusive look at upcoming product and feature releases – including a first hand demo of product enhancements that will help with intelligent test orchestration of feature branches for quality releases from your CI build server.
Assaf is the Product manager of Continuous Delivery Director. In the last 23 years, he has developed, designed, and managed products for the enterprise market, both for SaaS and on-prem.