At AWS re:Invent 2022 we launched Amazon CodeCatalyst, the new DevOps service for software development teams. CodeCatalyst is currently in public preview and available to developers. CodeCatalyst provides one place where you and your team can plan, work, collaborate on code, build, test and deploy applications. You can use CodeCatalyst to build your entire continuous integration and continuous delivery (CI/CD) pipeline within a single product. In this post, we’ll cover how you can migrate your CI/CD pipeline from Jenkins to CodeCatalyst, while retaining your preferred source control system.

You can get started with CodeCatalyst today at https://codecatalyst.aws/. CodeCatalyst requires an AWS Builder ID to get started. Builder IDs are a new personal profile for people building on AWS. A builder ID is usable across different AWS accounts. You can sign up for a Builder ID as part of the CodeCatalyst sign-up process.

Meeting developers where they are

Most developers already have some, if not all, of the components for a CI/CD pipeline. CodeCatalyst meets developers where they are, allowing them to adopt parts of the product, while retaining the existing functionality that they like. For example, if a developer currently uses GitHub for source control, and an on premises Jenkins server for build pipeline management, they can keep using GitHub for source control and migrate their build pipeline to CodeCatalyst.

Starting point

We will assume that you are currently using GitHub to store the source code for your project and you have a single Jenkins server deployed locally to perform automated builds.

Developers make code changes locally, and then push their updates to GitHub. Jenkins then provides the CI/CD services to build their code, perhaps also executing automated testing capabilities and pushing the build artifacts to a location such as Amazon Simple Storage Service (Amazon S3).

This blog post assumes that you want to continue to use GitHub for source control so that your developers don’t have to change their workflow and you don’t have to migrate your source code.

Adding CodeCatalyst

By adding CodeCatalyst to your current DevOps suite, you gain the benefits of a managed service. You no longer have to maintain your own Jenkins server on premises, saving you the cost of maintaining one or more servers, as well as the overhead of keeping both Jenkins and your Jenkins plug-ins up to date. As a managed service, CodeCatalyst is designed for high-availability, and automatically scales to meet spikes in demand. Additionally, if you are using on-demand compute fleets, when you are not actively building software, you do not have to pay for idle compute resources relating to your build systems.

Connecting GitHub

CodeCatalyst has an extension that you can enable to connect CodeCatalyst to your GitHub repositories. This will allow you to continue to leverage GitHub and take advantage of CodeCatalyst’s other features, like workflows to automate your build process and issue tracking.

Once you log into CodeCatalyst, choose the Installed Extensions tab.

Choose Browse the Amazon CodeCatalyst Catalog to list the available extensions.

Then install the GitHub Repositories extension by choosing the Install button.

CodeCatalyst will then walk you through connecting your CodeCatalyst account to your GitHub account. Once completed, you will be able to see your connected GitHub repositories in the CodeCatalyst console.

Moving from Jenkins

Creating a Project

CodeCatalyst manages your DevOps processes in projects. CodeCatalyst projects represent your software project and contain the tools and resources that you need to create, test, and deploy code, coordinate development tasks, and track project metrics. CodeCatalyst projects contain workflows that define the steps required to build, test and deploy the project that they are associated with. As you migrate from Jenkins to CodeCatalyst you will create a CodeCatalyst workflow for each Jenkins job. If you have multiple Jenkins jobs for a single repository, you can migrate these to multiple workflows under the same project

In the following example, I have a GitHub repository called PiTank. I have a Jenkins job called PiTank which contains all the build instructions to build, test and deploy my source code. Following best practices, all of the build steps for my Jenkins job are contained in a Jenkins file that is included in my source code. In order to remain consistent I want to migrate this Jenkins job to a CodeCatalyst project called PiTank.

In order to create the new project, you choose the option to Create a new project.

Select the option to Start from scratch. This will allow you to copy your build commands from the Jenkins file to the CodeCatalyst Project.

Once the project is created, you can edit the properties of the project by choosing the project name.

The project will initially have no source code repositories or workflows configured.

In Jenkins, locate the repository that you have configured for the job. This will be in the general section of the job definition.

You can link your source code to CodeCatalyst by selecting the Code option in the navigation panel, and then choosing Source repositories.

From the Source Repositories screen, choose the option to Add repository, and then Link repository.

You will now have the option to create a new repository in CodeCatalyst or link an existing repository.

From here, you can configure which repository provider, account and specific repository from that account that you want to connect to. In the example shown in the following image, I am connecting a GitHub repository called PiTank to my BasementProgrammer CodeCatalyst account.

Select the correct account and repository, and then choose Link.

Once you have linked your source code to the project, you can now create a workflow and move your Jenkins build commands to the new project.

Jenkins users will often store their build settings in a Jenkins file, doing so allows the build settings to be checked into source control. This best practice enables traceability for your build configurations, as well as backing up your build configuration, if the Jenkins server encounters a failure.

The easiest way to move your build settings from your Jenkins job into CodeCatalyst, is to open the Jenkins file in a code editor, and then copy your shell commands from the Jenkins file, to the CodeCatalyst workflow via the editor.

Back in CodeCatalyst, select the Workflows tab on your project.

Choose the option to Create a new Workflow. This will present you with an editor for an empty workflow. Choose the plus (+) button next to the Actions label to expand the prebuild actions panel. This allows you to add actions to your workflow.

CodeCatalyst has built in actions that correspond to the stages that are present in your Jenkins file. For example, in the following diagram we highlight Build and Test.

In order to add a Build stage to our workflow, we choose the plus (+) button in the lower right corner of the Build tile.

Adding the build item to your workflow, adds sample code to your workflow definition.

Update your workflow configuration by converting your “sh” commands in your Jenkins file, to run steps in your workflow actions.

For this blog post we are only concerned with the build commands, however a similar process should be used for other stages that you have in your Jenkins Job definition. Once you have copied over your commands, you can choose Validate to make sure that your YAML file is correctly formatted. Finally, choose Commit to commit the workflow to your source code repository.

When you choose Commit, you can provide a commit message.

Choose Commit to commit your workflow. By default, as soon as you commit your workflow, CodeCatalyst executes it automatically. This may not be the case if you have edited the workflow definition to change the configured triggers.

Choose the title of the workflow to see the process run through your first build!

Configuration files

Much like Jenkins, CodeCatalyst workflow configuration files are stored alongside your source code in the repository.

This process maintains your existing Jenkins file, allowing you to continue to use both systems in parallel during your testing phase. Once you are satisfied that all functionality has been migrated successfully, you can shut down your Jenkins server.

Additional DevOps capabilities

Once you have moved your build pipeline from Jenkins to CodeCatalyst, you can now take advantage of its other capabilities like managing pull requests, issue management and dev environments!

Summary

In this post we covered how you can migrate your existing CI/CD process from a self-managed Jenkins installation to Amazon CodeCatalyst, while retaining your preferred system for maintaining source code. Moving to Amazon CodeCatalyst eliminated the need to maintain on-premises servers for your CI/CD process. Following this procedure allows you to run both systems in parallel until you are comfortable that the new pipeline has been thoroughly tested and you are ready to cut over completely to CodeCatalyst. Get started with CodeCatalyst today at https://codecatalyst.aws/.