While we have in the past, and will likely in the future create additional branches that can deploy to an additional environment. Very rarely does this extra environment actually give the intended additional benefit. The few cases where it has added additional benefit is where it is for a migration from one core to another or something like that where it is a short lived additional environment and branch. Instead I recommend to research branching strategies and how to make your given environment configuration as good as possible before looking to add an additional environment and additional complexity.
I don't think my team does it the best, but I definitely think additional environments would make the problem worse than better. What my team does internally is we have our branch that is deployed to Staging and our branch that is deployed to Production. The merge requests always go linearly. I treat the merge request to Staging like that feature was going to production in terms of code quality and intention.
That being said, some features are "proof-of-concept" features and internally we have those too where we are working on a feature for many months and then have it available in production all at once. For these, I will still make sure the code is the quality for Production before going into Staging. The features that are not ready for production will be behind a feature flag which the SDK has very good support for feature flags between simply not installing the extension or a wedge address config turning that feature off. Of course, I am pushing these to Staging, but an important part of this is being able to also push this code to Production during my release of other code with confidence that it will not impact production.
Thus, I am almost always deploying from staging to production unless there is a strange case where I need to do a very quick patch deploy. That patch deploy code immediately goes from production back to staging.
@<1540019641223483392|Trey Teter> Thanks for the response! Would you mind expanding a bit more on what you mean by a feature flag? Is it each extension gets a config that basically toggles it on or off? I think our near future will be more POC work (as we venture into using the SDK) rather than fully ready production ideas, so will definitely need to balance deploying to production with POC efforts.
—Feature flag is more of a Programming concept of having a feature on or off based off of a config. Your Wedge_Adress_config is just an open field for configs that are environment specific that a Feature Flag implementation is perfect for on extensions that are running in prod but you need to add a large feature to. If it is entire extensions you can just not install them into your prod environment until you are ready. The code can be in Production but never installed and that is fine.(Think running your service but not doing q2 install)
—
While you’re bringing this up, I wanted to share a dilemma I’m running into with our master and production branches.
— Bradley Bell 8 months agoThe master branch currently contains both extensions that are actively being tested for production and proof-of-concept extensions that may never be deployed. As a result, master and prod are not in sync, and I can’t cleanly merge a specific extension directly from master into prod without running into merge conflicts.
My current workaround is to create a new feature branch off prod, manually move the extension code into that branch, and then merge it back into prod.
@<1607788563921899520|Bradley Bell> Yes, I think we too would hit that similar situation as we grow our development work.
— Bina Reed 8 months ago@<1607788563921899520|Bradley Bell> This is exactly what we do. When I'm ready to merge to production, I create a new branch off
— Brock Caldwell 7 months agoproductionand then checkout just the extension directory (plus config file, and any additional code) into new branch, like so: from my new branch (e.g.new-feature-go-live)git checkout master -- NewFeature/git checkout master -- config/NewFeature.py. Then commit and push. This pulls in those files and directories as they exist in the master branch, into my new 'go live' branch. I then merge that into the production branch. Not ideal, but it works.