Proposal: Start using feature branches

まず、ここで説明されている現在の develop-to-staging および develop-to-master のデプロイワークフローを確認し、API リポジトリがそれにどのように従っているかも確認します。提案されている feature-branch ワークフローと staging への影響について、プロジェクトチームと比較検討します。ブランチ方式とデプロイの扱いについて合意し、文書化されれば完了です。

Problem

This applies to our API repository as well.

CodeCorps is a project in big part built by volunteers.

Our current deployment system is as follows:

• A PR is submitted against develop
• The PR is approved and merged into develop
• If the develop build passes, this is deployed to staging
• When ready, we submit a PR from develop into master
• When this PR is merged and the master build passes, this is deployed to production

The advantage of this is that the process is quick and deployment is simple. We also only have to manage 2 environments and 2 sets of environment variables.

The disadvantage is, it's not very suitable for large, distributed teams.

Presumably, our volunteer force would like to and would probably be more productive if it worked on multiple features in parallel. When all PRs get merged into a single develop branch, there are bound to be clashes that way.

A potentially more effective approach would be to create a new branch for each feature to be worked on. PRs for that specific feature would be created against that branch and when the feature is ready, we create a PR from that feature branch into develop.

Benefits

A benefit of this approach is, it's easier to define requirements for the feature. For example, with the github connect feature, I had to write out our issues in such a way that the last issue to be resolved is the one which adds the connect button into the web application interface. This is constricting and wastes potential volunteer time, since that issue has to be marked as blocked until everything else is ready.

In addition to that, with the API, in the current system, it's difficult to add any new feature piece by piece. We generally do not want to open up API endpoints until everything else about it is ready, but we are sort of forced to do so. With a feature-branch based approach, this would not be a problem.

Disadvantages

It's difficult, though it might be possible, to maintain staging-deployment on feature branches. I'm not sure if I'm stating this clearly, but by that, I mean that, when submitting a PR against a feature branch and then merging into it, it would be difficult to configure our system to deploy that feature branch build onto a staging server of some sort. We'd have to have separate staging servers for each feature branch, with separate environment variables.

There may be a way to set things up so that the default staging server is somehow cloned onto a temporary feature branch server, but I've never tried anything like that, so I'm not sure. Could use some expert advice here.

That being said, the whole thing might not be necessary. develop would remain as is, so we just keep deployment as is. Feature branch has no staging. When we deem it ready, we merge into develop, which goes to staging.

Another disadvantage is we'd have to keep feature branches up to date from develop. Again, that might not be a huge deal, since we presumably would not be creating the final feature -> develop PR until we're done with the feature. At that point, we simply rebase and that's it.