- Development & Design Practices
- Front End
- How We Work
- Markdown How-To
- Using Git
- Internal Operations
- People Ops
- Sales & Marketing
# Release Process
There are two processes, one for major/minor point releases. The second for patch releases.
# Major/minor point releases
- Decide who will be Release Manager for this release. For Major/Minor releases this should be shared across the whole team to prevent it becoming a single point of failure. For Fix releases it can be the developer committing the fix.
- Create a Release checklist issue using the Release Checklist template
- Assign the issue to the Release Manager
- Ensure you have the following installed on your machine:
- git command-line tools.
- GitHub client
- Ensure you're machine is authenticated with the GitHub client:
gh auth login
- Ensure you are able to access the FlowForge repositories using the git cli without being prompted for a password:
ssh -T firstname.lastname@example.org
- When we are ready to start the release process the Release Manager should start a Slack Huddle in #dev and keep that open until the release is completed.
# Unmanaged Repositories
Not all repositories are covered by the release automation and must be published separately. This is typically done by the development team in the build up to the full release.
The Release Manager should verify the following repositories are up to date and have been published as needed.
Refer to the section Unmanaged Releases for releasing these.
flowforge/adminrepository if you do not already have it.
- Ensure you have the latest with a
- Ensure you have the latest with a
In the parent directory to where you have the
adminchecked out, run:
This will create a directory called
release-0.x.yand checkout all of the releasable repositories under it.
NOTE: If you do not have a global git configuration, you will need to set
user.emailin each of those repositories.
Within the release directory run:
cd release-0.x.y ../admin/prepare-release 0.x.y
This will check all of the repositories are ready to be released, update their
package.jsonfiles to reflect the new version (including cross-package dependencies) and update the CHANGELOG files.
It will then raise PRs against each repository with these changes in.
Do not panic when you see "All jobs have failed" for the
flowforge/flowforgeRelease PR. This is due to the repo pointing to newer versions of other packages which have not yet been published to npm.
Follow through the current release checklist in
flowforge/adminin the order they are listed. Each PR will need to be reviewed, merged and tagged taking care to verify each one has been published before moving to the next. Some steps will also require you to pause and re-run tests before continuing. Updated packages will be automatically published to npm by our GitHub actions. You can check the publish status of these as follows:
- Track the "Release Published" action on the GH repository
- Keep an eye on npmjs.org page for each package
- Watch for bot notifications in the #gh-flowforge Slack channel (NOTE: the notifications can take quite a while to appear in the channel)
Once all the node module components have been built and published to npm the
docker-composecomponents can be updated and tagged.
Run staging CI pipeline publish, to ensure staging is running the latest release.
# Next Steps
- As much as possible of the previous steps should be converted into a CI Pipeline making use of GitHub Actions.
# Patch releases
Patch releases are done as needed and have a much lighter process to allow fixes to be released quickly.
flowforge repository has some automation in place to help with this process. Until that is rolled out across the other repositories, some of the backporting work must be done manually.
- Changes must first be PR'd to the
mainbranch and reviewed in the normal manner.
- Before merging, the PR should have the label
- If in
flowforge/flowforge, when the PR is merged, an automation will run to create a new PR that backports the change to the maintenance branch. Otherwise, the backport PR must be manually created.
- The backport PR must be reviewed and merged in the normal manner.
- Once all of the required backport PRs are merged, raise a PR on the
maintenancebranch to update the version and
CHANGELOG.mdfile with suitable details.
- Create the GitHub release with the appropriate
Finally, create two change request issues in the admin repo, one for staging and one for production to upgrade to the latest version.
# Unmanaged Releases
The unmanaged repositories listed above have a simpler release process.
- Make announcement in #dev so team is aware
- Check that all changes have been merged to main
- Update package.json version number
- Run the
flowforge/adminrepository. This generates a list of the PRs merged since the last tagged release. Note: this script require the
ghcli to be installed and logged in. Update CHANGELOG.md with the output of the script.
- Open a new PR to merge the package.json and CHANGELOG.md changes - get it merged
- Tag new release in GitHub with the appropriate version number eg
v0.1.1. Copy the CHANGELOG update into the description.
- Once the release is created, the GitHub Action will take care of publishing to NPM. Check the action to ensure it completes.
# Launch Lunch
To celebrate the launch of a new version of FlowForge, we organize a lunch on the release day. See also the peopleops section.