Commit eb6355bc authored by Farley's avatar Farley

Added release schedule guide

parent 583c53d7
NOTE: This is a guide used by OlinData BV for handling releases of OpsTheater. As an end user you do not need to use this guide.
Release cycle
Problems notwithstanding we release a new version of OpsTheater every month on the first of the month. Our timing is based on and coincides with a number of the software packaged within OpsTheater. Security releases are published when needed. Our changelog for the release will contain changes, new features, and packaged software version information.
Release timing
Monthly release, the 1st day of every month.
Patch release, for serious bugs or security problems.
Monthly Release Internal Process
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/
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.
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. 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.
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.
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.
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.
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