2

We have our existing code repository in GitHub. This code is in folder structure resembling eclipse IDE forlder structure(or probably they call it metadata structure), like src --> classes --> myclass.cls.

We have a sandbox org that is shared for development among 4-5 developers. We want to set up a process of Source control management with this.

Approach 1 Our approach for this is: 1. Create branches in github for each developer and each developer will pull code from his/her respective branch locally in VS code. 2. Each developer will also have org code retrieved in his VS code(that will be synonymous to master code in GIT).

Now the requirement is that once a developer makes a change in one of the files, and saves it, and then deploys it back to org, it should also be tracked by source control in VS code, so that developer knows that he has to check those changes in.

How can this setup be done in VS code without changing the folder structure that is there currently in GITHUB(metadata structure)? I ask this because folder structure of code fetched from VSCode is different. So how can these 2 things be synced and tracked in 1 single project?

Approach 2:

Another approach is create 2 folders/projects in VS code, 1 that contains repository branch cloned code and 1 that contains code from org. Now developer will make changes in org code and whenever he is done, at the end of the day, he will compare it with GIT code o his branch and merge the changes in git code and check that code in. This individual branch will then be merged with master branch via a pull request.

Which is better approach of these 2? Which one is a continuous Integration approach?(I think approach 1)

Improve this question
3
  • 1
    And what goals are you trying to achieve with having a code repository? Should you're repository be a backup of your developments in the sandbox? Do you want to allow developers to work in isolation, e.g. seperate environments (Sandboxes/scratch orgs) and integrate in your repository? Do you want to create a deployment pipeline from your repo? Understanding your goals would make it much easier to recommend a possible solution.
    – Magnus Kreth
    Commented Sep 23, 2019 at 13:06
  • @MagnusKreth : We want it because: 1. Backup, 2. We want devs to work in isolation but it won't be possible as we have single dev org for all, will it? 3. We want to maintain all code at one place. This means all code from various teams, modules that will finally go live in prod, but may not be related to each other. 4. We do not want to do deployments from repo.
    – Sarang
    Commented Sep 23, 2019 at 14:50
  • 3
    I'd respectfully suggest that this solution is a chimera. It is hobbled by a core architectural limitation - the single development org without deployment control - that prevents you from using source control or continuous integration in any best-practices sort of way. Instead of investing heavily in systems built around that limitation, I'd work to change it first.
    – David Reed
    Commented Sep 24, 2019 at 13:20

1 Answer 1

Reset to default
3

There could be multiple use cases for introducing a source code repository into your Salesforce development process.

Metadata backup

You could create backups of your metadata at regular intervals in a source code repository. This would give you a history and also some traceability, e.g. knowledge when something was introduced. The simplest approach to a metadata backup would probably be a full metadata retrieve which you could then check into your source code repository. No sophisticated branching strategy would be needed because you really just need the history information.

Isolation

You wrote that currently all your developers are working in a single developer sandbox. Could you achieve isolation by letting them commit their work to a source code repository individually? You'd have to work for that. But for what benefit? Isolation by itself won't provide you any additional value. Isolation may allow you to do more in parallel though - there are some that say you can better scale if you allow a certain degree of autonomy in your team(s) compared to having the whole team being aligned all times. This kind of isolation is though only really achievable if you completely isolate the work of individual developers or sub-teams from others. The source code repository could then be the point where changes from different developers or sub-teams are integrated. This integrated view in your source code repository would become your source of truth. But this would also be the source of any deployment then (because it is your only complete source of truth now). It comes quite natural to setup a continuous integration / deployment pipeline from such a source code repository. However now you also have to take care about providing the integrated results into the development environments of each individual developer or sub-team. If they are using sandboxes you'd have to take care of regularly deploying from your integrated (branch) version in the repo to those sandboxes. On the other hand with scratch orgs which are shortlived and can be thrown away once something is committed to the source code repository this comes naturally.

In short: in large (whatever number that means) teams people will start standing on each others toes at some point if they're working in a single development environment. Using isolated development environments and integrating results in a source code repository can help with scaling up teamsize. But you need to take care of getting the integrated results back into the individual development environments. Use scratch orgs to simplify this.

Deployments

My personal perspective comes largely from doing project work as a system integrator for clients. A project is typically - in my world at least - developed over a certain time, then you have a thorough test phase and finally a release. A release is something fairly large. I do like that with having individual commits to a source code repository over the timespan of a project you get a history of changes resulting in a fairly complete picture of what changes are part of your release. At the end of the release we would typically do a full deployment from the source code repository to UAT/PREPROD and finally PROD stages. With some discipline (e.g. commit message which reference your work items, i.e. Jira issues) you can have a nice traceability from your code/config changes to a requirement, e.g. your able to answer when and why a certain change was introduced. And the totallity of your customizations in the source code repository is what makes up your release. This allows to setup things like continuous integration or continuous deployments. After each commit to your repository you can trigger something that tests your release and provides immediate feedback whether something is wrong with your release. You could have automated tests on different levels of sophistication, e.g. unit tests, integration tests, automated end-to-end tests. Even automated user acceptance tests. This could then give you a lot of confidence to say: we're ready to move this into production. Or you could stop after automatically providing a new release in a testing environment.

Improve this answer
1
  • I understand what you are telling here. But due to some reason we can't have different dev orgs/scratch orgs per developer. IN this case what could be the suggested approach of the 2 approaches I mentioned?
    – Sarang
    Commented Sep 24, 2019 at 9:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .