The Release Process

Code delivery process from develop to master.

start:release - Start release branch

Checkout develop branch:

git checkout develop

Run:

cells start [ --targetBranch release --branchName release/tutorial ]

[14:23:42] Execution contexts: [ recipe, develop ]
[14:23:42] Starting flow: [ start ], steps: [ start, setVersion, push ]
...

If targetBranch parameter is not set Gluon will ask:

? What do you want to start? (Use arrow keys)
  new feature
❯ new release
  new master merger

If branchName parameter is not set, you will be asked for the name you want to give the branch:

? Write the name of the new release (release/ is already appended) tutorial (better without spaces)

The creation of a release branch will change the version of the develop branch. To perform this process Gluon will ask you to choose next release type, to be able to establish the appropriate version.

? Choose next release (Use arrow keys)
  major
  minor
❯ patch

IMPORTANT: During the development process is possible to change the type of release manually anytime if is necessary by changing the version file.

Once the execution is finished check that you are in the branch that you just created:

➜ pisco-git git: (release/tutorial) git branch -l
  develop
* release/tutorial
  master

Conclusions:

• 1. The release branch is used to make small corrections to problems detected in the release phase. In this phase several test cycles are performed, such as acceptance and user tests. (See piscosour-gitflow methodology document)
• 1. Work on this branch normally with your favorite tools.
• 1. When you start a release branch, the develop branch raises the chosen interval (major/minor/patch). (f.i. for the minor of x.y.z-beta.n to x.(y+1).z-beta.0)
• 1. Only one release can be made in parallel.
• 1. Note that the versions in this branch are this type x.y.z-rc.0.
• 1. Note that a tag of type pre_x.y.z-rc.0 has been created with the initial state before starting to work.

finish:release - Delivery code to master

checkout release:

git checkout release/tutorial

Run:

cells finish

[14:24:52] Execution contexts: [ recipe, release ]
[14:24:52] Starting flow: [ finish ], steps: [ merge, validate, setVersion, finish, publish ]
....

Conclusions:

• 1. IMPORTANT: IN CASE OF CONFLICT BY MERGING CODE HAS PREFERENCE CODE COMING FROM RELEASE
• 1. IMPORTANT: Changes made in the release branch, while the process has lasted, must be manually merged into develop. Gluon will help you in this process: [see section Master-to-Develop Mix Mixing Process] (#Process-of-merging-from-master-to-develop)
• 1. The changes of the develop branch and those made in release will have been delivered to master.
• 1. All the tests implemented for the repository will have been executed on the result of the merge of release branch with master. If the tests do not end OK, the process will not continue.
• 1. The version will have automatically changed in the master branch depending on the release version from x.y.z-rc.0 to x.y.z in master. The change in the release branch is determined by the response to the question that was asked in the previous release. (major/minor/patch).
• 1. The release branch has been deleted.
• 1. A tag x.y.z will be generated with the status at the time of delivery.
• 1. The corresponding artifact has been published in the corresponding register with the version x.y.z

Common Problems:

• 1. Validate ends with errors. If this happens the process will stop and none of the actions will be carried out.

Solve the tests so they do not give error.