2

I am the only Salesforce developer in my current company and I built the integration software package completely from green field. Basically we are aiming to provide a free download app in Apex Exchange to integrate with our main product.

Currently I structured the development and testing org in a pretty simple way: One dev org to develop and build managed package. One (or more) testing org to install the latest package and do testing. I used git to do the version control. But it only keeps the source code without building into Salesforce orgs.

I thought it was okay since I am the only developer. But it proved out that I was wrong. First, even in the foreseeable future I would be the only Salesforce developer, I should consider for team expansion. Second, there are features I want to develop in my developer org but don't want to affect the end user's usability. Which means, the bug fixing and new feature will take place in parallel but only bug fixes should be merged into package org.

So the consideration should conclude with separation of development and packaging orgs to me. Am I thinking it correctly this time? If so, how should I integrate the metadata between dev and package orgs then? As I have already created a managed package in my package org.

2

You should have a one developer org for development and that will connect to dev branch in your github repo.

I would also prefer a separate org for testing and a separate org for feature build and have a git branch linked to feature development org.

A master branch where you want merge everything and then use that to deploy to packaging and build a package .

Also use releases feature of git to hold zip file of code of all releases

Using Git branching should help you to do a PR before you merge so that you can find diff between packaging and the PR request .

Also i would set up a CI like jenkins or AutoRabit or Circle CI to do automatic build and deploy but if you are comfortable you can also run an ANT command to build the org(Not recommend if you have multiple developers ) .

In short follow the github workflow and its easy to onboard devs

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.