Commit f7e2d003 authored by shreejit's avatar shreejit

adding more steps

parent 47cfdb59
Pipeline #70 skipped
......@@ -17,26 +17,32 @@ Patch release, for serious bugs or security problems.
# Monthly Release Internal Process
1. The process starts the 23rd of every month, in which we evaluate the stability and inclusion of newer versions of our included packages. The release manager decides on a version of all supporting packages and creates a ChangeLog to be included with the release and documented in this repository under releases/x.x.x_changelog.md
1. The process starts the 23rd of every month, in which we evaluate the stability and inclusion of newer versions of our included packages. The release manager decides on a version of all supporting packages and creates a ChangeLog to be included with the release and documented in this repository under releases/x.x.x_changelog.md
2. First thing that occurs the release manager creates a release-x.x.x tag from the master branch. Typically monthly releases are sub-releases, so it should increment the Y in x.y.z, making 1.2.3 into 1.3.0. The final version octet is reserved for emergency bug/security patches, and the first octet is reserved for us to designate major evolutions in the software at our own discretion.
2. First thing that occurs the release manager opens a issue for the new release and to keep track of the release. You can refer this one for example : https://gitlab.olindata.com/opstheater/opstheater/issues/10
3. From this release branch, the release manager attempts a fresh installation of all of the currently supported services on a staging-ish environment, typically using our primary provider DigitalOcean or a local vagrant setup.
3. After this the release manager creates a release-x.x.x tag from the master branch. Typically monthly releases are sub-releases, so it should increment the Y in x.y.z, making 1.2.3 into 1.3.0. The final version octet is reserved for emergency bug/security patches, and the first octet is reserved for us to designate major evolutions in the software at our own discretion.
3. list out current stable versions of the tools included in opstheater
4. From this release branch, the release manager attempts a fresh installation of all of the currently supported services on a staging-ish environment, typically using our primary provider DigitalOcean or a local vagrant setup.
4. If this installation happened without problem, then (ideally) a fresh installation is setup from the previous release, and an upgrade installation is performed and tested. This above process is expected to take 1-3 days depending on our level of automation and problems occurred during installation/upgrading/testing. Patches can be made to fix any release problems and committed directly to the release branch to be merged back into the master with a PR after released.
5. Form this local installation release manager will make a list out current stable versions of the tools included in OpsTheater.
5. If the release testing will take more than 3 days, we evaluate the progress, changes, and situation and consider postponing deploy or proceeding with it.
6. If this installation happened without problem, then (ideally) a fresh installation is setup from the previous release, and an upgrade installation is performed and tested. This above process is expected to take 1-3 days depending on our level of automation and problems occurred during installation/upgrading/testing. Patches can be made to fix any release problems and committed directly to the release branch to be merged back into the master with a PR after released.
7. We create release notes and a blog post for the olindata.com blog.
7. If the release testing will take more than 3 days, we evaluate the progress, changes, and situation and consider postponing deploy or proceeding with it.
8. Schedule tweets and a mail to the mailing list also.
8. Create release notes and a blog post for the olindata.com blog.
6. After a release is tested for installation and upgrading, we upgrade our internal core opstheater installation, so we are consuming what we're creating. This needs to be done at least 4 days before the end of the month, so that we can have at least two working days with our platform upgraded to settle any potential longer-tailed issues with the upgrade. If any issues arise, the release manager can either opt to fix them and commit to the release branch, or to rollback the platform to the previous release depending on the severity and estimated time to fix.
9. Once the upgrade installation is succeeded then release manager need to create a new branch in opstheater-docs reposiroty cloning previous release branch and need to update the documents in the new branch according to the new release for example release manager need to update upgrade.md with the steps that need to be performed for upgrade installation.
7. When the first of the month rolls around, if there were no problems with the release, a release is created in github from the release branch, and any changes made are PR'd back to the master branch for approval by another core team member. This tag is not to be purged after the PR is merged to master, but to remain in git forever.
10. After this release manager need to update releasechecklist.md in current release branch of opstheater-docs. releasechecklist.md will contains the basic steps that release manager needs to perform once the upgrade is finised to make sure that all opstheater components are working fine.
8. At this point, we send an update notification email to any subscribers to OpsTheater mailers and begin the process to upgrade all of our OpsTheater installations that are paid subscribers. As part of the signup process with our customers, we decide on a day-of-the-week and time to perform maintenance on their OpsTheater. Following their requested schedule, we perform the necessary upgrade, and inform our customers of this 2 days before, and if there is no objection then also notify them as we begin the upgrade procedure, and after its completion along with a changelog of any platform changes/improvements/etc.
11. Schedule tweets and a mail to the mailing list also.
9. a tarball of the pre-release branch named after whatever version tag it then has
12. After a release is tested for installation and upgrading, we upgrade our internal core OpsTheater installation, so we are consuming what we're creating. This needs to be done at least 4 days before the end of the month, so that we can have at least two working days with our platform upgraded to settle any potential longer-tailed issues with the upgrade. If any issues arise, the release manager can either opt to fix them and commit to the release branch, or to rollback the platform to the previous release depending on the severity and estimated time to fix.
13. When the first of the month rolls around, if there were no problems with the release, a release is created in github from the release branch, and any changes made are PR'd back to the master branch for approval by another core team member. This tag is not to be purged after the PR is merged to master, but to remain in git forever.
14. Now release manager can close the issue which he created for this new release.
15. At this point, we send an update notification email to any subscribers to OpsTheater mailers and begin the process to upgrade all of our OpsTheater installations that are paid subscribers. As part of the signup process with our customers, we decide on a day-of-the-week and time to perform maintenance on their OpsTheater. Following their requested schedule, we perform the necessary upgrade, and inform our customers of this 2 days before, and if there is no objection then also notify them as we begin the upgrade procedure, and after its completion along with a changelog of any platform changes/improvements/etc.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment