Proposal: Start using feature branches

Bắt đầu bằng việc xem xét workflow triển khai hiện tại từ develop-to-staging và develop-to-master được mô tả ở đây, bao gồm cả cách repository API tuân theo workflow này. So sánh workflow feature-branch được đề xuất và các ảnh hưởng của nó đối với staging với nhóm dự án. Công việc được xem là hoàn tất khi cách tiếp cận branching và việc xử lý triển khai đã được thống nhất và ghi lại.

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.