I am new to Salesforce and have few questions on the ways of developement and adoption of package model

  1. I have started working for a fairly large organization that uses Salesforce extensively and does lot of customizations. They use changesets to move changes from one environment to another. Is this a recommended approach for an organization with 400+(or may be more) users or should they switch to package model.

  2. Can we configure DevOps when using changesets. Does it make sense to export the code using metadata api and run tests etc. or is there any recommended way to bring in elements of DevOps when using changesets. I do understand that the source of truth would be the production org and not source control.

  3. I happened to come across a blog that states there is no single way to move from changesets to developer controlled packages. We can start creating packages by trying to create an unmanaged package through package manager, pulling the code from the org using salesforce DX CLI and storing in a source control system. Is there any other recommended way of untangling metadata by salesforce.

  4. Is developer controlled packages still in beta, is it mandatory to use SFDX when we start using packages.

Hope the questions make sense. Any corrections are welcome as i am new to salesforce and trying to get my basics right.

Regards, Ranjith


I work for Gearset, and we talk to lots of folks with these sorts of questions, so here are my two cents based on that :)

  1. This answer to this question is less about the size of your org / number of users etc., and more about the makeup of the team responsible for maintaining your orgs, their technical experience level, and organizational appetite for change. If you've got a couple of admins and a dev maintaining your environments, and their existing process is working for them, then adopting something like DX (with or without packaging, which is a different question I think) might be overkill, if those devs and admins aren't familiar with things like git, the CLI, etc. It's definitely a good aspiration to adopt more modern tools and practices, but the challenge first and foremost will be one of people, rather than technology. Re: packages, what makes you immediately reach for them as a solution? In my experiences, adopting something like 2GP is still a non-trivial decision for teams that are already keeping the majority of their metadata under version control and using the CLI, whether DX or Ant. I tend to see adopting DX and version control as an important intermediate step, before thinking about packaging. Note that packages come with a whole bunch of software engineering challenges of their own, in terms of cross cutting concerns, versioning, reducing coupling, identifying boundaries, etc. - again, if you've got an experienced team with a strong engineering discipline then have at it :)

  2. I think the short answer is "not really" - I think DevOps implies things like using version control, and lots of automation and monitoring, all of which are tricky / impossible with change sets. That's not to say that you can't get some of the benefits of DevOps tools whilst still using change sets - you can incrementally adopt tools and processes that might help. You could, for instance, set up a cron task that will run the unit tests in your org and generate reports when test coverage falls or tests start to fail, while still using change sets for your deployments. You could extend this to do things like notify you when your org changes over time, so you can start to audit the types of changes that are being pushed to production. You could then tentatively start using VCS as a backup, just to get your metadata under version control, by periodically pulling code from production and committing it to your git repo. You can build this stuff yourself with scripts and a CI server like TeamCity, Bamboo, Jenkins, Cricle CI, etc., or you can use an off-the-shelf solution built for Salesforce, like Gearset (amongst others). So you can sort of start to incrementally adopt some DevOps-style processes while using change sets, but it'd be interesting to know exactly what problems you're facing before making a recommendation here.

  3. The sentiment of that blog post sounds accurate to me :) As I've already mentioned, I wouldn't start out by worrying about packages, I'd start out by starting to pull metadata into version control and building my release process around that. There are a bunch of tools that will let you pull and push changes between orgs and git repos in a manner familiar to change sets users. The important thing is that packages aren't necessary to start working from version control and to start on that DevOps journey. Get that up and running, then start to look at which parts of your org might be easier to untangle into packages.

  4. I believe developer controlled packages are still in beta, and yes they're part of DX. In my day job, the teams that I speak to that are using 2GP in anger are those that are comprised almost entirely from fairly experienced developers, or at least have a strong engineering discipline with an experienced lead driving the adoption of DX, and helping take the rest of the team on that journey.

I hope those answers help - this is a topic that's interesting to me, and I'm happy to talk more about it. If you want to jump on a call to talk at more length then let me know - promise I won't try to sell you anything :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.