Overview

CI Pilot aims to provide direction and guidance towards setting up the ideal software delivery pipeline as well as fully automating it.

Production releases

There are plenty of incredible players on the market that aid in production release management and publishing, and CI Pilot doesn't aim to compete with them, rather to bridge the gap and standardise their use in coordination with your Git methodology (focusing on GitHubFlow and GitFlow).

Pre-production releases

Looking at the most well used release management tools (semantic-release, standard-version, etc.), there's a clear lack of in-depth focus on how to go about producing internal packages during the development life-cycle, pre-production. CI Pilot steps in with out of the box support for the following:

1. Feature/Bug-Fix/Hot-Fix branch alpha releases, Git tagging the branch and publishing a package
2. For GitFlow adopters, Alpha releases, Git tagging the development branch and publishing a package

Getting started

Install

npm:

npm i --save-dev ci-pilot

Yarn:

yarn add -D ci-pilot

Commands

Supported commands:

1. publish
2. release-gh-gf
3. helper

Publish

ci-pilot publish [stage]

Publish a feature branch

ci-pilot publish feature

Release GitHub-GitFlow

ci-pilot release-gh-fg [step]

Cut a new release

ci-pilot release-gh-gf cut

Stage a release via a Git tag

ci-pilot release-gh-gf stage

Finish a release

ci-pilot release-gh-gf finish

Additional command-line flags:

• --auto-bump-change-log or -a: This flag when specified will use standard-version under the hood to generate the next release version based on the Conventional Commits preset chosen, bump the package.json version, generate or update the change log, and Git tag the commit with the version.
• --merge-msg-skip-ci or -m: This flag will suffix GitFlow merge commits with [skip ci], a common convention used to avoid additional jobs being triggered in your CI pipeline.

Scrap a release

ci-pilot release-gh-gf scrap

Helper

ci-pilot helper [helper]

Cut a new release

ci-pilot helper package-name

Stage a release via a Git tag

ci-pilot helper is-repo-gitflow

Configure

Create a file called ci-pilot.config.json in the root of the repository, and populate it with the following:

Default (fully expanded):

{
  "packageManager": "npm",
  "gitMethodology": "...",
  "branchNames": {
    "base": "master",
    "feature": "feature",
    "hotfix": "hotfix",
    "development": "develop",
    "bugfix": "bugfix"
  },
  "release": {
    "preset": "angular",
    "tagPrefix": "v"
  },
  "gitBranchSeparator": "/",
  "tagSeparator": "#"
}

Alternate example:

{
  "gitMethodology": "...",
  "branchNames": {
    "base": "main",
    "feature": "topic",
  "gitBranchSeparator": "-",
  "tagSeparator": "$"
}

Configuration Options:

• packageManager: Options, npm or yarn, defaults to npm
• gitMethodology: Mandatory, GitFlow or GitHubFlow
• branchNames.base: Optional, defaults to master
• branchNames.feature: Optional, defaults to feature
• branchNames.hotfix: Optional, defaults to hotfix
• branchNames.development: Optional, defaults to develop
• branchNames.bugfix: Optional, defaults to bugfix
• release.preset: Optional, defaults to angular
• release.tagPrefix: Optional, defaults to v
• gitBranchSeparator: Options: / | -, defaults to /
• tagSeparator: Options: # | £ | $, defaults to #

Note: CI Pilot uses your package manager of choice under the hood, npm or yarn. Ensuring that your CI pipeline is configured correctly for npm or yarn remains your responsibility and is out of scope for CI Pilot.

Ethos

We have different recommendations on how to use CI Pilot based on the progress of the code change through your software release pipeline - see details below.

Developing features

Publish your feature package

Publish packages on features you're developing by adding the following command as a step in your CI pipeline:

ci-pilot publish feature

Note: We don't recommend committing feature branch versions bumps to Git, as the pre-release alpha versions would eventually be merged into base or development branches which is wrong. Instead we believe that Git tags are sufficient to mark the origin of built packages that are uploaded to your package registries.

Our strategy:

1. Version the package(s) in the repository locally
2. Publish the packages (containing the package.json file for built assets contain the alpha feature version)
3. Wipe away the version changes in the Git working tree

If you're working in a mono-repo then the above command will detect that and by default publish all workspace packages. If you wish to only publish only one of the packages in the mono-repo then you should include the --package-only flag otherwise the command will fail, as it's not our recommendation.

Contributors ✨

Thanks goes to these wonderful people (emoji key):

This project follows the all-contributors specification. Contributions of any kind welcome!

License

MIT