Jenkins configuration to support multi-config multi-branch CI

Question

Here are my requirements and I go back-and-forth on how to achieve them:

• Must build Java spring-boot apps
• Artifacts must be released to artifactory repository
• Docker image to be built directly relating to the artifact group/artifactId/version
• Docker image to be deployed to AWS ACR
• Container deployment via cloud formation
• Maintain 2 branches in a git repo: dev and master. dev releases to our development environment and master is for prod (I have tried to explain that this approach made sense when code was app (php) but not when you have a release artifact)
• All branches off dev must build and test independently but NOT release even snapshots (doesn't apply to master as no one should be working off master)
• best part dev and prod builds must be done under entirely different AWS credentials and accounts into totally different VPCs

Given these requirements I believe need a multi-configuration pipeline - one for the {prod/master} and {development/dev} arrangement to successfully capture the credential and deployment differences and point them at different branches. What I can't seem to do is get the dev configuration to ALSO build the branches from dev - I have no pattern I can match - the branches don't look like dev-.* - they are mapped directly to Jira tickets.

Can I even do such a thing? I feel like this last part is where my multi-config is breaking down.

Answer 1

You can use a Jenkinsfile for this. You can add logic with groovy for every condition you've listed above.

You'll want to use a multi-branch pipeline build for sure, and just write in conditions / switches to determine what you want to do based on the current branch. Jenkins provides a global environment variable for all builds: BRANCH_NAME

The job will run on any branch that contains the Jenkinsfile and you can write conditions in for steps if you want to include / exclude certain branches. You can use the when directive for full-step conditions: https://jenkins.io/doc/book/pipeline/syntax/#when

For handling credentials: https://jenkins.io/doc/book/pipeline/jenkinsfile/#handling-credentials

Answer 2

My two cents with respect to AWS part:

• If you have to use different VPCs, and accounts in AWS, I suggest you should have a look at AWS IAM roles and assign appropriate policies to the roles; also, ensure these roles are associated with AWS EC2 instance profiles that can be attached to EC2 instances, if they are used as build agents. That way you won't have to store AWS credentials but go with AWS STS.

• As you have mentioned about AWS ECR, let me tell you about Docker Plugin installed -- with these plugins, Jenkinsfile can become very crisp to write and maintain using the steps exposed by the plugin, including the tasks to build the image, tag the image and push the image to the registry.

• Better yet, you can have metadata YAML for every service / component that can specify details about AWS ECR and write Groovy scripts to detect the change to YAML, only then build new version of the Docker image.