2. Development Workflow¶
Contents
2.1. Description¶
The CELESTE development cycle consists of “branch -> commit -> review -> merge” cycles for all future code changes. To summarize:
- The developer checks out a new branch
- The developer commits code to the branch and pushes to the remote Source Control Management system (SCM)
- The developer commits code to the branch
- The developer opens a pull request (PR) for merging code changes in
- Reviewers review the code and put comments/suggestions
- The developer address fixes/issues/complaints/questions made by the code reviewers
- Code reviewers approve the PR and merge the side branch in.
To maintain stable releases but allow for active development,two long-standing git branches are maintained:
develop
branch - This is where active development occursmaster
branch - This is where the release versions are maintained
Changes from the develop
branch will be merged to master
on a release-update basis.
2.3. Rationale¶
Reasons for adopting this standardized workflow include, but is not limited:
- Preventing developers from making bad changes to the main working branches
- Unifying development efforts, as opposed to having developers branch off forever with different variants of the codebase for different fixes and features
- Enforce knowledge transfer among the developers through code reviews, so that the project does not die
- Bring some control and sanity to the development of CELESTE
- Enforce consistent quality in software delivery for CELESTE users
2.4. Enforcement¶
To enforce this workflow, the following rules must be enabled in the hosting SCM:
- No direct pushes to
master
, except by the integrator. - No direct pushes to
develop
, except by PR approval. - PRs are blocked from the approval threshold unless the associated branch passes build and tests.
- The
master
anddevelop
branches are locked from forced pushes / overwrites, but allows overwrites for all other branches.
Currently, CELESTE is hosted on the public version of Bitbucket, which has limitations prventing us from enforcing the above rules. There is an ongoing effort to (re)build the infrastructure using Jenkins and Gerrit in order to enforce these good software engineering practices.
2.5. Workflow-Supporting Git Usage¶
CELESTE uses git
for source code version control, and as such, developers should familiarize themselves with advanced git
commands through Select Advanced Git Usage to support this workflow.
2.6. Continuous Integration (CI) and Delivery (CD)¶
While not in place at time of writing, Jenkins will be used for CI and CD. Jenkins allows for the following to be done automatically in response to codebase updates:
- Preventing PRs from being approved if the associated branch failed to build or failed tests
- Enforcing coding style conformation
- Automatically deploy new documentation and binaries for code updates to servers