-
Notifications
You must be signed in to change notification settings - Fork 19
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
Update our EDD process documentation #166
Conversation
No New Or Fixed Issues Found |
Deploying with Cloudflare Pages
|
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.
Few things to consider.
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.
💭 What id we sliced this up into thirds so it can be read top to bottom?
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.
Took a stab at refiguring the image. Thoughts on the new format?
There are some unique constraints to Bitwarden that are not addressed directly in Martin Fowler's | ||
EDD article. | ||
|
||
- Our Production instances in the cloud are required to be on at all times |
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.
⛏️ When possible I think it's a good idea to eliminate personal pronouns; there's a lot of "our" and "we" in this document.
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.
I removed all of the personal pronouns that I added. I did not update the documented process that already existed.
|
||
### Devops | ||
### Cloud Environments |
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.
💭 Is "cloud" the term we want? Or perhaps more generically "online"?
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.
I went with "always-on" over "online" to avoid the ambiguous "online application" possibly referring to any application on the internet. Thoughts?
@@ -72,4 +72,15 @@ pwsh ef_migrate.ps1 [NAME_OF_MIGRATION] | |||
|
|||
This will generate the migrations, which should then be included in your PR. | |||
|
|||
### [Not Yet Implemented] Manual MSSQL Migrations |
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.
❓ Will this effectively be implemented once we publish these documents though?
Also, there's a few references in this document to "future" that you're limiting on the EDD one.
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.
I don't think so. We need to implement EDD as soon as possible because we are already using EDD without the processes to support it in the new EU environments and also in the self-host environments. I am considering this out of scope for the EDD process implementation and do not have a timeline on when we will get to this. I'm hoping that this note here will avoid the issue that we are running into now with needing to scramble to add in automated processes to support all of our environment types.
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.
Some initial thoughts.
There are some unique constraints to Bitwarden that are not addressed directly in Martin Fowler's | ||
EDD article. | ||
|
||
- Our Production instances in the cloud are required to be on at all times | ||
- Our self-host instances that we do not directly have access to manage must support the same EDD | ||
processes; however, they do not have the same always-on application constraint | ||
- Minimization of manual steps in our process |
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.
These are in my opinion all considered in the article.
- That's the purpose of EDD.
- Self-hosted does not really need to support EDD, the current deployment mechanism turns off the server,r runs migrations and starts the new code instances. I.e. there is no transition phase.
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.
I've updated the language a bit to focus more on the implementation of orchestrating EDD in our environment rather than EDD itself.
After reading through Fowler's article, I came away with the impression that the purpose of EDD is not to support an always-on DB/application. He went so far as to say that it would take a whole separate article to examine the technicalities to orchestrate EDD in such an environment. I think it is important to keep the always-on requirement for orchestration in mind.
I see this a different way. Exiting the Transition Phase is not done until the Finalization migrations have been run in the next update. If every release of server has destructive DB changes, I would say that the self-host deployment will constantly switch from one Transition Phase to the next.
We tweak the terminology to be more easily understandable in how EDD relates to our deployment | ||
processes in both our environments: our always-on application in the cloud and our self-host | ||
deployments. We use the terms: _Initial_ Phase (instead of _Start_), _Transition_ Phase, and | ||
_Finalization_ Phase (instead of _End_). |
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.
I'm always hesitant to diverge from established naming but I wonder if start
here more accurately refer to the beginning of the development work, not deployment.
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.
I agree. I have updated the terminology to better align with the diagram and not redefine the established naming. The added "types" of migrations is to help overlay EDD on the deployment process and to clearly communicate between Development and *Ops the expectations that come with those migrations.
functionality | ||
- Supports both the previous version of code and the one being upgraded to | ||
- Run during upgrade | ||
- Must execute quickly to minimize downtime. |
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.
Define quickly. Do you mean non-locking, or few operations?
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.
With k8s deployments, the goal is to get an end-to-end automated deploy finished within ten minutes. DB migrations are run in a serial manner. So any DB changes that put this initial target at risk would be considered "not quick enough". Any schema changes that put this target at risk should be flagged for more in depth discussion to see if it can be moved to during the Transition Phase.
#### Initial Phase | ||
|
||
- Compatible with <i>previous</i> <b>and</b> <i>next</i> application code changes | ||
- Represents the beginning of a database change | ||
- Updates our database schema to support any new functionality while also maintaining old | ||
functionality | ||
- Supports both the previous version of code and the one being upgraded to | ||
- Run during upgrade | ||
- Must execute quickly to minimize downtime. | ||
|
||
#### Transition Phase | ||
|
||
- Compatible with <i>previous</i> <b>and</b> <i>next</i> application code changes | ||
- The time between initial migration and finalization | ||
- Exists to provide an opportunity to rollback server to _previous_ version prior to breaking | ||
changes | ||
- Only data population migrations may be run at this time, if they are needed | ||
- Optional step, required only when migrating data would be too slow to execute during the initial | ||
migration. This might be a column population, index creation, anything to prepare our database | ||
for the _next_ version | ||
- Must be run as a background task during our Transition phase. | ||
- These MUST run in a way where the database stays responsive during the full migration | ||
- Schema changes are NOT to be run during this phase. | ||
|
||
#### Finalization Phase | ||
|
||
- Only compatible with <i>next</i> application code; represents the point of no return for this | ||
migration | ||
- Removes columns, data, and fallback code required to support _previous_ version | ||
- Should be run as a typical migration either during a subsequent upgrade |
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.
I'm not a fan of these lists, i don't believe they convey much information and they are hard to understand.
I wonder if it's better to look at the transitions instead of the phases. There are two database transitions and in between these transitions we could if we want have any number of code deployments.
- Migrate to a database structure that supports old and new schema.
- Migrate to a database structure that only supports new schema
- Migrate data
- Migrate structure
The problem occurs because Migrate data can be both load and time consuming, and should therefore be done at our convenience in order to minimize database load. It technically doesn't need to be executed until just before the next code deployment if that simplifies things.
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 for the feedback on the lists. What format would you suggest to use to clearly define each of these types of migrations? Clear understanding of them is important for developers putting new migrations in the correct places in our implementation of EDD in our deploy processes.
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.
Still reviewing this, going to continue tomorrow but here are some comments. I also rebased #165 on top of this.
import refactoringPhases from "./stages_refactoring.jpg"; | ||
import eddStateMachine from "./edd_state_machine.jpg"; |
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.
Is there a reason for importing images this way?
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.
Yes. To support JSX for this feedback: #166 (comment)
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.
We don't need JXS though. It works just as well to define the image link in the html.
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.
Any suggestions on the change? I tried updating the usage of the the JSX and it led to a broken link:
<img src='./stages_refactoring.jpg' alt="Refactoring Phases" />
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.
This document should be written with the aim to give a high level overview of how Evolutionary database design works.
Developer focused documentation on how to write migrations should be in either the MSSQL or EF files.
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.
What portion of the article does not line up with the high level overview of EDD?
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.
Thank you for your work on this!
Co-authored-by: Thomas Avery <[email protected]>
@joseph-flinn I rewrote portions of this in #184, let me know what you think. |
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.
|
||
### Developer | ||
Schema migrations and data migrations as just migrations. The underlying implementation issue is |
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.
Schema migrations and data migrations as just migrations. The underlying implementation issue is | |
Schema migrations and data migrations are just migrations. The underlying implementation issue is |
@Hinton Thanks so much! I think they are all great rewrites. I left a couple of comments in conjunction with the ones from @withinfocus |
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.
@joseph-flinn could we add the source to this image if we need to modify it in the future?
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.
I haven't focused on the deployment orchestration since it's outside my area of expertise, but the rest of the document looks good to me.
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.
These are a lot of changes over a long period of time so I think it's best to get this in and do another round once we finalize the actual changes DevOps is making.
…ps/migrations * 'master' of github.com:bitwarden/contributing-docs: (37 commits) chore(deps): update dependency cspell to v7.3.7 (#206) [PM-4161] Fix build command on README.md (#207) Fixed typo in csharp.md (#180) Update our EDD process documentation (#166) chore(deps): update actions/checkout action to v4.1.0 (#204) chore(deps): lock file maintenance (#205) fix(deps): update npm minor to v2.4.3 (#203) use dash when running self-hosted dotnet profile (#202) chore(deps): update actions/checkout action to v4 (#191) chore(deps): lock file maintenance (#201) chore(deps): update npm minor (#195) fix(deps): update dependency docusaurus-lunr-search to v3 (#200) setup_secrets: Pass `-clear` as switch (#194) Update KeyConnector docs for ARM Macs (#171) Lock file maintenance (#193) Update dependency cspell to v7.3.5 (#192) Update dependency ubuntu to v22 (#174) Update gh minor (#181) Feature flag documentation updates and mentions about new local override capabilities (#187) Update npm minor (#188) ... # Conflicts: # custom-words.txt # docs/contributing/database-migrations/edd.mdx # docs/contributing/database-migrations/index.md
Objectives