Thanks in advance. We developed a managed package into a partner developer org (PDO). Namespaces is already created in PDO. Now we would like to leverage SFDX. I would like to have environment strategy like Developer Env -> Testing Env -> UAT -> STAG -> PROD. My questions Will I be creating UAT, STAG, PROD org in my partner business org? If yes after development/testing in scratch org I merge changes to UAT branch which should deploy changes to UAT sandbox. How would this application work on UAT sandbox as namespace is attached with code? Anyways we have to push final code to partner developer org.
I work at Salesforce.org, where we created and use the free and open source CumulusCI (CCI) to manage the builds and environment generation for products like the Nonprofit Success Pack.
CCI prescribes "CumulusCI Flow", which is a branching and workflow model specifically designed for building managed packages using SFDX and scratch orgs. (CCI is in essence an orchestration layer on top of SFDX, which can be run locally or using a CI system). In full CumulusCI flow, the only persistent environment you use is your packaging org, and no work is done directly there; instead, all development is done in feature branches in scratch orgs, and is deployed to the packaging org only when merged to
UAT and other testing environments can be, and should be, scratch orgs. CCI provides the tools to automate setting up these environments for the use of different parts of your team, such as a customizable
qa_org flow to build a quality assurance environment. Investing in this build automation pays off in the long term because you're guaranteed reliable, reproducible environment setup that's easy to pivot to new versions or different branches, without having to maintain the state of persistent orgs.
Our developers add features to our managed packages using SFDX and scratch orgs, and our Continuous Integration uses those too via https://claimvantage.github.io/sfdx-jenkins-shared-library/. Scratch orgs support namespaces.
But at the moment, the package version upload is done back in the old developer edition org by doing a:
followed by a:
then followed by a manual version upload. Not too big a burden, as for us this is typically the final step after several weeks of feature development.
Eventually, packaging 2 should simplify this and make it more automatable.
This single command:
can be used in place of the two convert/deploy commands.