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.
Add a comment
|
2 Answers
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 master.
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.
answered Aug 25, 2019 at 20:58
-
1Thanks for the detailed explanation. Unfortunately Cumulus CI supports only GitHub and we are using Bitbucket so probably I will have to drop the idea of using Cumulus CI. But if I don't use and go through SFDX + Git flow using Bitbucket how will I involve QA people /Business User for manual testing that too knowing the fact that each developer will have their own set of scratch orgs for dev, qa and uat...correct me I am wrong. Commented Aug 26, 2019 at 17:06
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:
sfdx force:source:convert
followed by a:
sfdx force:mdapi:deploy
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.
PS
This single command:
sfdx:source:deploy
can be used in place of the two convert/deploy commands.
-
Have you tried sfdx:source:deploy instead of converting? Any challenges there? I've been out of the ISV game for a few years now, curious if it has any unusual hurdles compared to mdapi.– sfdcfox ♦Commented Aug 26, 2019 at 7:44
-
@sfdcfox Will definitely try
sfdx:source:deploynext time; I assume it will work.– Keith CCommented Aug 26, 2019 at 8:51 -
-
How do you remember what was added/changed by the devs in their Scratch Orgs? I assume you are updating the managed package manually after the deployment stage, right?– MossiCommented Sep 12, 2019 at 3:03
-
1@Mossi Devs push their changes into GitHub (where the push automatically identifies and handles all changes) and the process to get the code into the managed package is to pull all changes from GitHub and then deploy that (so again everything is automatically handled). There is no manual change tracking.– Keith CCommented Sep 12, 2019 at 7:09