Skip to main content
Version: ACE 5

Development workflow

This guide describes example branching model and pipeline for ACE development.

ACE application consists of 2 components - ACE runtime and workspace. ACE runtime executes flows and APIs which are defined in workspace, so ACE workspace should be treated as a code and managed using same techniques as code.

Each project have its own requirements, therefore branching model and environments, but this guide describes example project environment and branching model which can be tweaked to project needs.

This guide assumes that releases are done at regular intervals (i.e. 2 weeks or monthly).

Branching model​

Branching model described here is Trunk Based Development approach with short-lived feature branches for feature/bug development and release branches for release management.

Typical branches in this model are:

  • master - main branch which is used for work integration
  • Short-lived feature branches which are used for tasks or bugs. Prefixes are not important, but good idea is to start branch name with ticket number, for instance DIG1111-add-footer. Project can decide to use feature/, bugfix/ and /hotfix prefixes if that helps semantically.
  • release/* - release branches to stabilize current release or provide support for release in production

Releases are tagged in git, so that it's always possible to go back to a particular release and provide a support.

Environments​

Example setup assumes that there are 3 environments. Depending on project needs there may be more environments for various purposes.

DEV​

Development environment. Environment purpose:

  • Continuous integration of all development work
    • Automated deployments of master branch
    • Run quality checks - unit/integration/end-to-end tests
  • Host shared development tools (i.e. ACE Designer Web)
  • DevOps change development/testing

TEST​

Release test environment. Environment purpose:

  • Release stabilization
  • Hotfix testing
  • Test system behaviour in other release
  • Automated deployments of release/* branches (optional)

PROD​

Production environment for project or released version(s) for product.

Versioning​

Suggested approach is to use Semantic versioning with dev suffix for development versions.

It means that master version will always end with dev pre-release identifier (i.e. 1.2.3-dev.12, but release/* branches will not have pre-release identifier (i.e. 1.2.3).

Scenarios​

Develop a new feature​

  • Developer creates a branch for task from master
  • Developer makes changes
  • Developer creates a Pull Request
  • Reviewer approves Pull Request
  • Developer merges changes back to master
  • Pipeline bumps master version to prerelease (i.e. 1.2.3-dev.0 -> 1.2.3-dev.1) and tags it
  • Pipeline builds artifacts (Docker images) with the new version
  • Pipeline deploys changes to DEV environment
  • QA tests changes in DEV environment

Create a new release​

  • Release is created from master branch shortly before release to stabilize a release
  • Release manager creates release/<version> branch
  • Release manager bumps master version to preminor (i.e. 1.2.3-dev.5 -> 1.3.0-dev.0) and tags it
  • Release manager removes prerelease suffix from release/<version> version (i.e. 1.2.3-dev.5 -> 1.2.3) and tags it
  • Pipeline builds artifacts (Docker images) with the new version
    • This artifact can be deployed to all necessary environments, including PROD
  • Pipeline deploys changes to TEST environment (optional, can be done manually)

Development bug in DEV​

  • Same approach as for new feature

Bugfix (bug in TEST)​

  • Developer creates a branch for bugfix from develop(!)
    • This is important as changes made to release/<version> are not merged back to master
    • Exception is cases when it's not possible to repeat issue in master
  • Developer makes changes
  • Developer creates a Pull Request
  • Reviewer approves Pull Request
  • Developer merges changes back to master (changes are deployed and tested in DEV as usual)
  • Developer cherry-picks changes to current release/<version> branch and creates a second Pull Request
  • Reviewer approves Pull Request (optional)
  • Developer merges changes to release/<version>
  • Release manager bumps release/<version> patch version (i.e. 1.2.3 -> 1.2.4) and tags it

Hotfix (bug in PROD)​

  • General approach to hotfix in PROD is exactly the same as for bug in TEST
  • First bug is fixed in master
  • Changes are cherry-picked into target release/<version> branch which is currently in PROD
  • If necessary changes are cherry-picked to other release/<version> branches, including next release branch if it's already created
  • If branch is deleted or doesn't exist it can be created from deployed version tag

Deploy changes to another environment (UAT, PROD)​

  • Release manager or DevOps deploys artifact (Docker image) which is built from release/<version> branch
  • Same artifact can be deployed to multiple environments
  • Deployment can be done via parametrized pipeline or manually by DevOps

Pipeline​

Development (CI) pipeline​

Development pipeline goal is to build master branch, deploy changes to DEV environment and validate changes.

Development pipeline works on master changes:

  • Bump prerelease version (i.e. 1.2.3-dev.0 -> 1.2.3-dev.1) and tags it
  • Build Docker images with the new version
  • Deploy changes to DEV environment
  • Run integration tests against DEV environment

New release pipeline​

Release manager tasks for creating new release can be automated via pipeline.

Pipeline receives <release name> argument and do following:

  • Create release/<release name> branch
  • Bumps master version to preminor (i.e. 1.2.3-dev.5 -> 1.3.0-dev.0) and tags it
  • Run release pipeline which removes pre-release suffix (i.e. 1.2.3-dev.5 -> 1.2.3) and builds release

Release pipeline​

Release pipeline goal is to build an artifact for release and (optionally) deploy it to TEST environment.

Development pipeline works on release/* (i.e. release/1.2, release/PI7) changes:

  • Bump patch version (i.e. 1.2.3 -> 1.2.4) or remove pre-release suffix (i.e. 1.2.3-dev.5 -> 1.2.3) and tags it
  • Build Docker images with the new version
  • Deploy changes to TEST environment
  • Run integration tests against TEST environment

Deployment pipeline​

Deployment pipeline is intended to take already built artifact and deploy it to necessary environment - TEST, UAT, PROD.

Pipeline receives version and environment arguments and installs version on given environment.