Create devblog for environment differentiation #4407
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
github-actions
bot
added
content
|
@mani-dbt interested in your thoughts here! |
@joellabes - Thank you for putting together this content. Very helpful to understand the Slim CI & differentiating CI & production environments (especially with new CI improvement of selecting an environment instead of a job). One comment I have is that in the data landscape image, we can remove "QA Schemas," as all the target tables would be written to temporary PR schemas during this Slim CI job. I'm also thinking that we can work on putting together another blog (different from the above) that explains how customers who want to manage DEV -> QA -> PROD deployments should configure their strategy. It would be for more advanced enterprise customers who need a QA layer in-between & NOT just dev & prod. Happy to collaborate on this with you. Attached is an image I've put together recently for a customer. |
Good spotting! fixed now.
Yes let's do it! |
website/blog/2023-11-06-differentiate-prod-and-staging-environments.md
Outdated
Show resolved
Hide resolved
website/blog/2023-11-06-differentiate-prod-and-staging-environments.md
Outdated
Show resolved
Hide resolved
website/blog/2023-11-06-differentiate-prod-and-staging-environments.md
Outdated
Show resolved
Hide resolved
website/blog/2023-11-06-differentiate-prod-and-staging-environments.md
Outdated
Show resolved
Hide resolved
website/blog/2023-11-06-differentiate-prod-and-staging-environments.md
Outdated
Show resolved
Hide resolved
|
|
||
| By using the environment as the arbiter of state, any time a change is made to your Production deployment it will immediately be taken into consideration by subsequent Slim CI runs. | ||
|
|
||
| ## The easiest way to break apart your jobs |
There was a problem hiding this comment.
This is great and probably the most important part of your post - would the flow work if we were to move this up to just below the intro so as not to bury the lede?
There was a problem hiding this comment.
I've changed the link in the bottom line section up top to link directly to this section - I think rearranging to explain how without first explaining why probably isn't ideal?
There was a problem hiding this comment.
A prime example of a "we're updating our best practices based on new features" variety of dev blog - great work.
Some blocking comments on prepping the blog aspects like release date and adding a truncate and then non-blocking thoughts on wording / flow / linking out.
|
Changes made, i also renamed the file which makes the diff a bit funky |
What are you changing in this pull request and why?
Adds a new developer blog article explaining the importance of splitting out your production and CI environments if you haven't already, to take advantage of dbt Explorer and the improved Slim CI experience.