-
Notifications
You must be signed in to change notification settings - Fork 64
Automation
Dan Ibanez edited this page Aug 30, 2016
·
5 revisions
Our automation system attempts to balance multiple needs:
- Provide developers with minimal workflow restriction
- Ensure personal copies are merged to a central location
- Ensure users receive stable software
- Ensure our public and private versions are well coordinated
The software repository setup is as follows:
- Each repository has exactly two branches:
master
anddevelop
. - All developers can modify the
develop
branch at will, without restriction. - No developer may directly modify the
master
branch. - Every day, an automated process will perform regression tests on both branches, and post the results online.
- Every day, an automated process will merge all changes
from the
develop
branch to themaster
branch if and only if the resultingmaster
regression tests pass. - Specific to SCOREC software, an automated process
will merge all changes from the open-source
master
to the privatemaster
, if and only if the private regression tests pass. - A select group of owners may modify
master
for the limited purposes of repairing the automated system, and repairing merge conflicts from the open-source to the private repository.
The following image illustrates the system:
This system maintains substantial freedom:
- There is no barrier to pushing changes to
develop
, encouraging most work to be done directly indevelop
. - Merges are automated, not manual, so there is no need to depend on someone's availability (or subjective judgement) to merge code.
The system also maintains high stability:
- It should be nearly impossible for the
master
branch(es) to fail regression tests at any time. - The only way to get one individual's changes accepted into
master
is to ensure they are compatible with changes by other developers. - The way to ensure the
master
branch behaves a certain way is to set up an automated regression test for it.
By default, most work should be pushed to develop
.
Forks and other branches can still be maintained for serious refactoring,
with conscious awareness that each day a version remains separate
decreases its probability of survival via merging.