5

We are a group of 5 developers and 5 project managers which using Salesforce. The developers are working with Sublime and MavensMate, and we want to start using a source control tool (Git) and I'm not sure what is the best way to do this. My questions are:

  1. Do we need to work each developer in a different dev environment? if not, is there any way to work in the same environment without step on each other's toes?

  2. The project managers just add metadata on Salesforce and not writing code, should they all work in the same environment or in a mutual environment with the developers?

  3. What is the right process for a developer from the moment he pulls the origin master from Git until he push his feature / component?

  • 4
    If you haven't already, read about the new Salesforce Developer Experience tools. Trailhead has a trail on this too: Get Started with Salesforce DX. Within that documentation you should find some recommended patterns that suit you. In particular, scratch orgs allow developers to get away from sharing orgs. – Keith C Dec 17 '17 at 14:52
  • 2
    Answers to this post are likely to be highly rooted in opinion. Not sure it is on-topic according to the help center. That said, it will be much easier if you put each developer in their own environments. Though you'll have to figure out merges and probably want to set up a good refresh cadence (possibly daily). – Adrian Larson Dec 17 '17 at 15:24
8

Do we need to work each developer in a different dev environment? if not, is there any way to work in the same environment without step on each other's toes?

When developers work in the same org, they tend to overwrite each other's work. You can avoid this with frequent communication and setting up some safeguards in each IDE (like checking the modified stamp before each commit, doing merges, etc). At minimum, developers need a CVS (Git or SVN, for example) in order to fix the mistakes that will happen from time to time.

This was the inspiration for DX. In DX, each developer creates temporary orgs that are used for development. One environment per developer. If you decide not to use DX, you should still have each developer in their own org. Pre-DX, the typical scenario would be that each developer gets their own sandbox. Unfortunately, sandboxes tend to not get refreshed regularly, which has its own complications. If practical, move to DX.

The project managers just add metadata on Salesforce and not writing code, should they all work in the same environment or in a mutual environment with the developers?

Metadata should also be in your repository. Like code, it can conflict if incompatible changes are made. Also, it makes it more likely that a developer will accidentally wipe out some configuration (say, a validation rule) if they are not aware that such changes have occurred. Also, a metadata change (again, a validation rule) could result in failed unit tests or code that breaks because of the new rules. PMs should also work in scratch orgs and also commit changes to the repository.

What is the right process for a developer from the moment he pulls the origin master from Git until he push his feature / component?

The general process is as follows:

Create a Branch

In your repository, create a new feature branch to work on. You'll use this to keep your changes separate until you're ready.

Create an Org

Create a new scratch org or Sandbox. This should ideally be done weekly or sooner with scratch orgs and sandboxes. You can use Developer Orgs, but that tends to complicated after a while, so developers tend to only create them infrequently. They also have the smallest storage space, and so are rarely useful for continual development.

Push Code

Update the sandbox, developer, or scratch org with code from the repository. This should be done periodically throughout the process as well to avoid working with old code and metadata.

Do Development

Use the IDE of your choice, or if using DX, you can work directly in the org and pull changes back to your repository.

Run Tests

Make sure all unit tests are created and updated, and test before committing.

Commit to Feature Branch

Save your changes that you've made in your feature branch with commits to make sure that you don't lose your changes.

Do It Again

For longer features, you may end up starting over from the Create an Org step several times, possibly merging the parent branch back into the feature branch to keep code up to date.

Merge Final Changes

Finally, once the feature is complete, the changes are merged to the parent branch. There's a few merging strategies that will depend on your exact cycle, but typically expect a few more orgs between this point and production, usually a QA and a UAT org for quality assurance testing/bug finding and user acceptance testing for users to test new features before they're implemented globally.

Note that there are several different, valid types of development cycles that may be more or less complicated than presented here, and its worth the time to do some research, experiment with a few models, and tweak it to suit your needs. It also depends on your methodology, such as Agile or Scrum development, and other tools you may be using.


Note

This is a big one. Developers should typically not be pulling from master unless they're doing hotfixes. This tends to lead to all sorts of nasty merge conflicts later on down the road. A better approach is a multi-branch strategy. Master represents a golden copy, the state of production. Hotfixes should be branched from master since they need to happen first/fast. There should also be at least one branch (probably two) that are used for QA and UAT. UAT should be branched from master, and QA from UAT. feature branches should come from the QA branch. Definitely do your research before starting down a particular branching strategy.

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.