Document the deployment process #125
Conversation
|
|
||
| * **How can I test my database schema changes before attempting to deploy them to production?** | ||
|
|
||
| Launchpad as 2 pre-production environments, ``qastaging`` and ``staging``. The former is primarily |
There was a problem hiding this comment.
| Launchpad as 2 pre-production environments, ``qastaging`` and ``staging``. The former is primarily | |
| Launchpad has 2 pre-production environments, ``qastaging`` and ``staging``. The former is primarily |
There was a problem hiding this comment.
Thanks! This document will be very, very helpful, and not only to new joiners :-)
I would love to start with what you did, i.e. the clarification whether we want to deploy only code, or code and or only db changes.
While the only code path is much simpler, it involves quite some machinery, which I think makes sense to document clearly, i.e. the MP with target master, the merge via merge bot, the buildbot run, the autodeployment to qastaging.
And then handle the db flow separately.
So imho a structure like
- Intro
- db flow (maybe in future split into cold vs hot patches)
- code flow
would be ideal.
I am not sure yet whether it is possible to also include staging/qastaging in this document, to get the full picture, and without making things too confusing, but I think we need to try, as staging/qastaging are part of the complete flow, from a local code change to have things in production.
I would like to get this merged as soon as possible, but I think we need to iterate a couple of times on it.
|
|
||
| There is yet another Jenkins job on the OLS Jenkins instance that checks for new commits | ||
| to the ``db-stable`` branch and builds a new Launchpad payload for the latest revision in | ||
| the ``db-stable`` branch, and publishes to Swift, at a well-known location whose path contains |
There was a problem hiding this comment.
URL or any relative link to swift would be helpful for new folks.
| environment. This ``bundle.yaml`` file contains 2 different ``build_label`` values - the hash of the ``stable`` | ||
| branch commit that is deployed to production and also the hash of the ``db-stable`` branch commit that is | ||
| deployed to production. |
There was a problem hiding this comment.
Sorry, it confused me a bit here, whether the build_label is only used for deployments on production, or production and staging both. Do we specify commit hashes for both production and staging individually?
I think the earlier line states that bundle.yaml is generated according to environment but eventually it states that the build_label values are only for production. For staging I think its the latest commit that is used and we override build_label, but because we are talking about 2 environments in parallel its jumbling up a bit.
I am a bit confused here on behaviours for staging and production 🤔
There was a problem hiding this comment.
Looks good so far.
I would like to help with adding inline links to different jobs, repos, files we are talking about. So that its easy for any new user to find them.
Also, I think instead of bullet we should have all the questions as headings so they are easily distinguishable. Currently the page looks monotonous in the rtd preview because the font size is same for bullets and they have a very light bold style applied to them.
(Please ignore the failing CI checks. I will fix those before this PR is ready for review)