Git branches
There are four main branches used in the automated build process of the application:
- main - reflects the sources of the currently published application in the stable (latest) channel
- beta - reflects the sources of the currently published application in the beta channel
- alpha - reflects the sources of the currently published application in the alpha (dev) channel
- develop - the main working branch where a feature branches are merged into
The
main, beta, and alpha branches have CI scripts that perform a build once a branch is merged with them. They are testing the application (again) and run the electron-builder that is configured to build the application for Windows, macOS, and Linux. For the Windows and macOS builds the builder signs the application with configured certificates *these certificates are provided by MuleSoft). Additionally, the macOS build is notarized with Apple notarization service.When starting working on a new feature or a fix a new branch is created from the develop branch with a meaningful name related to the task, staring with
fix/[fix name] or feature/[feature name]. Once the work is done the branch is merged through a PR with the develop branch. This does not trigger any action.When a critical bug fix is to be released imminently after the application was patched the the flow starts with creating the
fix branch from the main branch. This is required as this branch gets updated the least and has the stable version code base while other branches may include features that are not yet ready to be published.After the work on the fix is ready the branch gets merged to all four main branches through a PR. With each merge the correct application version has to be set manually (ARC has not automatic version bumping logic). After the merge is completed for each branch the application is being released for the corresponding channel.
When a new version of the application is ready it goes through three stages of the release process.
This channel has always a one major version higher than the stable channel. This channel is to test new features. Each time a feature is merged with the develop branch and this feature is ready to be shipped in the alpha channel a PR is made to the alpha branch. Once the branch is merged an automated build is being triggered.
The beta channel has the next major version release candidate after all features for the release are finalized. A PR from the
alpha branch is being created with the updated version, which is one major version higher than the current stable application version. Once the PR is merged the build script is triggered.After release candidate from the beta channel is "enough tested" a stable release can be performed. Similarly to other channels, a PR from the
beta branch is being created. Once merged it triggers the tests and the build process.The release process in mostly automated as described above. However the automated publishing script does not actually publish the GitHub release. This is done manually by team members having a right to publish a GitHub release. This involves building a changelog as a release info and finally publishing the prepared binaries.
Last modified 2yr ago