Release Process

Welcome to the ciao wiki!

This page documents our development and release flows. It is WIP - and contains loose notes to begin formalizing how we will work.

Release Process

The ciao project will have a nightly release.

Nightly release versions will be datetime and not semantic based. We may in the future decide to do some semantic releases on a difference cadence, such as a once a month stable release.

At a specified time, the head commit of the master branch will be tested. If the tests pass, the master branch will be tagged at the commit with release tag and automatically do the release.

This can be automated using the releases API: https://developer.github.com/v3/repos/releases/#create-a-release

Or with something like this: http://www.rubydoc.info/gems/github-release/0.1.3

Because we are going to be doing fully automated test/release, we need to autogenerate release notes. The release notes can contain a changelog as well as the results of the QA tests. If you want images, such as a graph, you can use image links, but we’d need to host the images somewhere. We would love to have graphs showing metrics of the nightly releases, but that would seem to require a custom website.

Merging and Reviewing

Because the ciao master must always be ready to release, we should switch to pull requests only on master. We should switch our master branch to “protected” so that a pull request is required to pass all status checks before you can merge it. We can define which status checks must pass before merging is allowed.

https://help.github.com/articles/defining-the-mergeability-of-pull-requests/

https://github.com/blog/2051-protected-branches-and-required-status-checks

We should have 2 gatekeepers for master who can merge pull requests after the required checks have passed: one in Europe and one in the US to spread out the time we can have coverage for. We should rotate gatekeepers every 2 weeks so that nobody gets burnt out on it.

We could possibly use a github app called “https://github.com/integrations/pullapprove” and assign reviewers. Disadvantage is the lack of flexibility. You can set it to require only one of a group of people approve. So - the 2 designated master gatekeepers would be on the list for approval.

Additionally, each component will have it’s own gatekeeper. We can document that since it would not change frequently. Pull requests should be reviewed by component owner. The master gatekeeper can chose to review or not. The master gatekeeper can also assign other people to review and require that review prior to merging.

Can github pull requests be automatically assigned somehow?

If it’s your own code for your own component and you’re the master gatekeeper, it’d be best if the other gatekeeper reviewed and merged it.

Merge checklist

In order for a pull request to be merged, all the status checks must pass. In addition, the following manual checks should be made.

1. All the patches have a SOB (we could automate this and make it a travis check if we wanted to)
2. The patches were reviewed by the component owner at least
3. Did the change introduce any new 3rd party dependencies? If so, verify that the license is compatible.
4. Does the pull request require any documentation changes either for architecture or usage?
5. Any new functionality must have a unit test. Test coverage must not be lowered by the pull request.