deploy-process.md
1 # Ethereum.org deploy process 2 3 Ethereum.org follows a [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) workflow for managing and deploying the codebase. 4 5 ## Deploy process 6 7 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. 8 9 The typical workflow will be as follows: 10 11 1. A branch is created off of the `dev` branch, and pull requests for the branch are created into `dev` 12 2. Pull requests are reviewed, and merged into `dev` 13 3. On Tuesday, a pull request is created into the `staging` branch 14 - 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. 15 4. During the next 2 days (Tuesday - Thursday) QA testing on the release candidate takes place 16 - During QA testing, any bugs found will be filed under two categories: 17 - Release blocking: if a bug is considered blocking for the release, create an issue and triage for a pull request to fix before release 18 - Non-release blocking: if a bug is not blocking a release, create an issue and triage normally 19 5. If any release blocking bugfixes are merged into `staging`, bring those changes into `dev` 20 6. When a release candidate is ready for release, merge into `master` and deploy to production on Thursday 21 7. Create a tag for the new version in master 22 8. Merge tag into `staging` and `dev` 23 24 ``` 25 master O (tag) - - - - - - - - - - - - O (tag) 26 27 | / 28 29 staging O - - - - - - - - - O - - - O 30 31 | / \ 32 33 dev O - - - - O - - - - O - - O - O 34 35 \ \ / / 36 37 feature1 \ _ \ _ _ O / 38 39 feature 2 \ _ _ O 40 ``` 41 42 ## Release blocking bugfix process 43 44 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: 45 46 1. Create an issue in GitHub documenting the bug 47 2. Triage issue to a developer 48 3. Developer will create a branch off of `staging` 49 4. Work on bugfix 50 5. Create a pull request into `staging` 51 6. Merge into `staging` after review 52 7. Merge `staging` back into `dev` after the bugfix has been merged 53 54 ``` 55 master O (tag) - - - - - - - - - - - - - - - - - - - O (tag) 56 57 | / 58 59 | bugfix O - O / 60 61 | / \ / 62 63 staging O - - - - - - - - - O - - - - O - - O 64 65 | / \ 66 67 dev O - - - - O - - O - O - - - O - - - - - O 68 ``` 69 70 ## Hotfix process 71 72 In the event that a hotfix is found in production and needs to be addressed before the next release 73 74 1. Create an issue in GitHub documenting the bug 75 2. Triage issue to a developer 76 3. Developer will create a branch off of `master` 77 4. Work on hotfix 78 5. Create a pull request into `master` 79 6. After review, merge hotfix pull request into `master` and release into production 80 7. Merge `master` into `staging` and `dev` branches 81 82 ``` 83 hotfix O - - - O 84 85 / \ 86 87 master O - - - - - - - O (tag) 88 89 | | 90 91 staging O - - - - - - - O 92 93 | | 94 95 dev O - - O - - - - O 96 ``` 97 98 ## More about the Release Candidate QA process 99 100 The main idea behind the community QA process is to focus on the [current release changelog](https://github.com/ethereum/ethereum-org-website/releases) 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. 101 102 If you find any bug, please report it on the [#website-bugs](https://discord.com/channels/714888181740339261/727898649006309377) Discord channel.