-
Notifications
You must be signed in to change notification settings - Fork 967
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
docs: Production deployment guide skeleton #629
Conversation
Signed-off-by: Dorian Johnson <2020@dorianj.net>
|
||
Thus, the suggested setup is to fork the main `amundsen`, but to *not* fork the individual service repositories. Note that your fork must be private, since you will have configuration files inside. | ||
|
||
So the first step is to create a private fork of the public repo. The steps differ based on the repo host you use. |
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 sure if this is the right approach. If a bunch of people are deploying forks of amundsen
, it could constrain what kind of stuff we put in there, or when we bump versions.
Another option would be for us to create a separate repo from amundsen
that included more of the build scripts etc, and was intended to be private-fork.
I initially went down the route of suggesting people fork the individual repos, but it was an absolute mess, and I don't think we should recommend that to anyone.
Especially seeking feedback here.
* frontend - pull code from remote repo, rebuild | ||
|
||
|
||
TODO: how to coordinate versions? |
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 sure how to tell which versions are compatible with other versions -- do we document this somewhere?
I'm closing this. We're going to test and iterate something along these lines in the Stemma repo, then once they're battle-tested, we'll upstream them with a PR |
Signed-off-by: Marcos Iglesias Valle <golodhros@gmail.com>
Signed-off-by: Marcos Iglesias Valle <golodhros@gmail.com>
Signed-off-by: Marcos Iglesias Valle <golodhros@gmail.com>
ref: #53
Summary of Changes
This is a skeleton of a guide to running Amundsen in production. The intention is to create an opinionated guide that gives specific instructions on how to manage customizations, upgrades, etc. Per the plan for this mini-project, at this phase I want feedback from community members who have run Amundsen in production, before I start digging deeply and filling in details.
Reviewer notes: this guide is probably 15% done, vast majority is TODO'd. I mostly want feedback at the level of "is this even a reasonable way to do this?", "here's how we do it at X, and why we made that decision", "I don't think this is something we should be recommending to users" or "I think this format will make the guide hard to follow". Or even just replying to this doc with a brief summary of how you do it at your company would be helpful. I recommend starting at
deployment_guide/index.md
.Note: I'd like for this to land into a feature branch, until it lands. Could someone with write bits create a feature branch for this?
CheckList
Make sure you have checked all steps below to ensure a timely review.
cc @jornh