Ethereum.org deploy process

Ethereum.org follows a Gitflow 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 is as follows:

A branch is created off of the dev branch, and pull requests for the branch are created into dev
Pull requests are reviewed, and merged into dev
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.
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
If any release blocking bugfixes are merged into staging, bring those changes into dev
When a release candidate is ready for release, merge into master and deploy to production on Thursday
Create a tag for the new version in master
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:

Create an issue in GitHub documenting the bug
Triage issue to a developer
Developer will create a branch off of staging
Work on bugfix
Create a pull request into staging
Merge into staging after review
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

Create an issue in GitHub documenting the bug
Triage issue to a developer
Developer will create a branch off of master
Work on hotfix
Create a pull request into master
After review, merge hotfix pull request into master and release into production
Merge master into staging and dev branches

    hotfix O - - - O

         /           \

master  O - - - - - - - O (tag)

        |               |

staging O - - - - - - - O

        |               |

dev     O - - O - - - - O

More about the Release Candidate QA process

The main idea behind the community QA process is to focus on the current release changelog and check that new features or fixes applied are working as expected. During QA sessions, some notes could also be shared if we're looking for specific things to be tested.

If you find any bug, please report it on the #website-bugs Discord channel.