Skip to content

Workshop Addendum

Why Move

CircleCI libraries are protected only by being unpublished. CircleCI does allow restricting by IP address, but only at an additional charge.

CircleCI in the past has made changes that have had financial implications as well as unplanned work that was necessary. One example of this is the changing of the default instance size of their runners. This caused an unexpected increase in price as well as unplanned work to set the expected instance sizes for the runners.

Team onboarding and offboarding is heavy and manual due to Bitbucket's lack of integration with Okta (SCIM). In addition, the BitBucket API is limited which allows access controls than desired.

Key Similarities

Configuration of workflows for both CircleCI and for GitHub Actions is done in YAML.

The top level in both CircleCI and in GitHub Actions is Jobs. A workflow can define one or more jobs and those jobs can each have one or more steps.

Both CircleCI and GitHub Actions allow steps to be reusable as well as being shared among teams.

Key Differences

Solution Level Differences

GitHub Actions uses GitHub Hosted Runners where CircleCI has leveraged Docker Containers that run within CircleCI hosted Runners.

GitHub Actions workflow runs are visible within the GitHub UI alongside the code, pull requests, etc. CircleCI however does not display workflow runs in a consolidated view. It is a separate web portal from BitBucket. Consolidating tools gives better, wider and faster visibility to workflow runs.

Feedback on GitHub Actions vs. CircleCI has been positive with most stating GitHub Actions is easier to learn and adopt.

GitHub Actions improves security over CircleCI in that GitHub allows repo base secrets whereas CircleCI has generally used organization based secrets. Additionally, client name created Actions are only visible within the client name GitHub organization. CircleCI orbs are protected only by being unpublished.

Workflow Level Differences

CircleCI implements a single workflow file config.yml which defines all workflows. The direction for GitHub Actions workflows has been to define multiple yml files to break the workflows up and improve readability. Generated projects from backstage will be created with a dev-release.yml, qa-release.yml and prod-release.yml.

Job Level Differences

The typical implementation in GitHub Actions is to have fewer jobs with more steps within those jobs. CircleCI workflows typically define many jobs, but with few steps.

GitHub Actions implements job dependencies via the 'needs' syntax where CircleCI uses 'requires'.