-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document the deployment process #125
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)