3 ms·
My team comprises 4-5 Software Engineers and 1 Developer-in-Test. We develop three (related) websites + a bunch of back-end services. There is only one long-li
by M2Ys4U 10y ago
My team comprises 4-5 Software Engineers and 1 Developer-in-Test. We develop three (related) websites + a bunch of back-end services.
There is only one long-lived branch in each of our repositories: master. All other branches in our GitHub repos exist only to perform a Pull Request/code review.
PRs must not be merged in to master until all unit tests are passing (the unit test suite is run for each new commit to a PR branch) and the change has been reviewed by another member of the team. In almost all circumstances the person who raised the PR is responsible for merging it. Once the PR has been merged in to master the GitHub branch is deleted.
Our CI server creates a new build for _every_ merge commit to master, automatically pushes this build to our integration environment, and then runs a series out automated integration tests on the system. If the build or automated tests fail then only PRs that fix the build are allowed to be merged in unless they are trivial.
Once our DiT is ready to perform a test, she promotes a build to the test environment and does her thing. Tickets that have been tested are then reviewed by a product owner and if they are happy the build gets promoted to the Live environment.
- lamontcg 10y ago+1 on only having master as a long-lived branch. where we started 5 years ago at work we had various different kinds of 'develop' branches and process around merging between two different eternal branches. as we've scaled from a startup to a 200+ person company we've mostly simplified our github workflow and gone to single-eternal-master.