In typical java environment, after code quality test, we package code and push it to artifactory as snapshot, and then bring it to desired environment (dev/test/pre-prod) and deploy same. As I’m new to this SF platform, I’m curious to know and utilize artifactory in CI/CD pipeline but not sure at what stage of build process we can leverage this tool when we are into salesforce org base development model. Can inputs from this community is highly appreciable.


Salesforce development does not produce externalizable artifacts other than source code. You can, of course, use any applicable tool you wish to managed releases of your source code, but there's no packaging or compilation process you can apply off-platform.

You may choose to practice the Package Development Model to produce on-platform packages that can be installed in different Salesforce orgs, but those packages exist purely on the platform and cannot be stored externally. They are not analogous in many ways to packages in Java or other stacks. Note however that many Salesforce customers do not practice package-based development and never package their code; this is referred to as the Org Development Model.

The artifacts typically produced by a package development process are source code stored in version control, which of course you may associated with tags and releases in a system like GitHub, and the Ids of package versions that may be installed in Salesforce orgs.

Org development hopefully, in a best-practices context, is done in source control, and a well-managed development lifecycle may use tags, releases, or other artifacts to track specific deployments, but that's all dictated by the process of the org and again doesn't involve any compilation or packaging of the code as such.

| improve this answer | |
  • Any derived asset can be "managed" by (for example) pushing it to the repository or metadata service such as Artifactory. A change set is one example of a derived asset, it can even be thought of as "built" (assembly of an artifact is part of a build process). Whether any of this is a good idea or doable depends on CI/CD impl. – identigral Jun 25 at 17:53
  • @david reed: Thanks for your answer. As you pointed about tags, release etc for "org development model" in above comment, I like to check few things with you here, What is the best approach to set the release version in this org model (for example 1.1.2 etc ) ? and how do I determined it ? How can I track the components relate to each release ? and where do I keep record of this changing components for each release (artifactory, bitbucket, confluence etc ) – dinesh Jul 15 at 19:11
  • There are no standard answers to those questions, @dinesh, and the right ones will vary based on the specific business (and compliance) requirements in your environment. Personally, I'd probably tag, in Git, each revision that is deployed to prod with a date-based version stamp and call it good. GitHub or your host of choice can then easily generate diffs of changed components between releases. But again, it's all down to your specific requirements for change control and auditing. – David Reed Jul 15 at 23:59

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.