diff --git a/README.md b/README.md index ff2d53e94ae..df83a57639e 100644 --- a/README.md +++ b/README.md @@ -144,12 +144,12 @@ In case you want to test them as if you were in a Netlify env, you can install t - See [how decisions are made on content changes](https://ethereum.org/en/contributing/#how-decisions-about-the-site-are-made) - Acceptable PRs will be approved & merged into the `dev` branch -Learn more about how we review pull requests [here](docs/deploy-and-review-process.md). +Learn more about how we review pull requests [here](docs/review-process.md). ### 8. Release - `master` is continually synced to Netlify and will automatically deploy new commits to ethereum.org -- The [website team](https://ethereum.org/en/contributing/#how-decisions-about-the-site-are-made) will create deploys and merge `dev` into `master`. This happens on Tuesdays and Thursdays every week. More info on deploys and review process [here](docs/deploy-and-review-process.md). +- Learn more about how we deploy the site [here](docs/deploy-process.md) - You can [view the history of releases](https://github.com/ethereum/ethereum-org-website/releases), which include PR highlights
diff --git a/docs/deploy-process.md b/docs/deploy-process.md new file mode 100644 index 00000000000..b470c12a867 --- /dev/null +++ b/docs/deploy-process.md @@ -0,0 +1,96 @@ +# Ethereum.org deploy process + +Ethereum.org follows a [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) workflow for managing and deploying the codebase. + +## Deploy process + +The current process for deployment involves a 2-day QA cycle to test a release candidate. A release candidate is created on Tuesday, will have 2 days of testing, and then released to production on Thursday assuming no blocking bugs are found. + +The typical workflow will be as follows: + +1. A branch is created off of the `dev` branch, and pull requests for the branch are created into `dev` +2. Pull requests are reviewed, and merged into `dev` +3. On Tuesday, a pull request is created into the `staging` branch + - At this point, the `staging` branch will be the release candidate. At this point, no new features are added into staging for the release, only release blocking bugfixes. +4. During the next 2 days (Tuesday - Thursday) QA testing on the release candidate takes place + - During QA testing, any bugs found will be filed under two categories: + - Release blocking: if a bug is considered blocking for the release, create an issue and triage for a pull request to fix before release + - Non-release blocking: if a bug is not blocking a release, create an issue and triage normally +5. If any release blocking bugfixes are merged into `staging`, bring those changes into `dev` +6. When a release candidate is ready for release, merge into `master` and deploy to production on Thursday +7. Create a tag for the new version in master +8. Merge tag into `staging` and `dev` + +``` +master O (tag) - - - - - - - - - - - - O (tag) + + | / + +staging O - - - - - - - - - O - - - O + + | / \ + +dev O - - - - O - - - - O - - O - O + + \ \ / / + +feature1 \ _ \ _ _ O / + +feature 2 \ _ _ O +``` + +## Release blocking bugfix process + +In the event that a bug was found in `staging` during the QA cycle that blocks a release, the following steps will take place to address the bug: + +1. Create an issue in GitHub documenting the bug +2. Triage issue to a developer +3. Developer will create a branch off of `staging` +4. Work on bugfix +5. Create a pull request into `staging` +6. Merge into `staging` after review +7. Merge `staging` back into `dev` after the bugfix has been merged + +``` +master O (tag) - - - - - - - - - - - - - - - - - - - O (tag) + + | / + + | bugfix O - O / + + | / \ / + +staging O - - - - - - - - - O - - - - O - - O + + | / \ + +dev O - - - - O - - O - O - - - O - - - - - O +``` + +## Hotfix process + +In the event that a hotfix is found in production and needs to be addressed before the next release + +1. Create an issue in GitHub documenting the bug +2. Triage issue to a developer +3. Developer will create a branch off of `master` +4. Work on hotfix +5. Create a pull request into `master` +6. After review, merge hotfix pull request into `master` and release into production +7. Merge `master` into `staging` and `dev` branches + +``` + hotfix O - - - O + + / \ + +master O - - - - - - - O (tag) + + | | + +staging O - - - - - - - O + + | | + +dev O - - O - - - - O +``` diff --git a/docs/deploy-and-review-process.md b/docs/review-process.md similarity index 85% rename from docs/deploy-and-review-process.md rename to docs/review-process.md index 61c00bf09d9..4e34008d6fd 100644 --- a/docs/deploy-and-review-process.md +++ b/docs/review-process.md @@ -1,12 +1,6 @@ -# Deploy and pull request review process +# Pull request review process -This documentation outlines our current processes for how we deploy the latest changes to ethereum.org, and how we prioritize items in our pull request review process. - -## Deploy process - -Anything merged into the `dev` branch of [ethereum.org](http://ethereum.org) will go live on ethereum.org at the next release. Currently, we deploy the latest changes to [ethereum.org](http://ethereum.org) twice per week (Tuesday and Thursday). When deploying, we merge the `dev` branch into the `master` branch. The `master` branch is the latest live version of [ethereum.org](https://ethereum.org). - -Occasionally, we’ll also do a patch deploy to fix an urgent or widespread issue. +This documentation outlines our current processes for how we prioritize items in our pull request review process. ## Pull request review process