When I started working with Salesforce Development, I had several questions about development team best practices. My first researches pointed me to some lists of bad practices, which is not a problem, but is not an answer either. Since I doubted what I was doing, I started looking for better options that were and are available out there.
I started by reading the Salesforce Development Life Cycle Book, and I strongly recommend you do the same. This book has excellent references to developing in a team environment on the Force.com platform.
I come from a traditional application development background (.NET, Java, Oracle, etc.) and use source control like TFS, SVN, git and CVS. I have worked on traditional software where we have multiple branches going simultaneously and periodically merge and/or rebaseline.
I have tried the recommended best practice of each developer using their own sandbox, each one checking changes into a central repo (e.g., SVN), and getting each other’s changes by updating from the repo; all along, merging changes. That simply did not work and was not feasible for a project based contracting company to implement given time and budget constraints.
I don’t claim to bring anything revolutionary or new. On the contrary, my goal here is to organize existing great ideas, collected in several places, which together are extremely useful. That being said, I will outline what the best practice was, in theory, and then tell you an alternative.
I’ll just use SVN as the repo in my illustration.
Theoretically…
- Each developer has their own sandbox and their own SVN account.
- Developer makes changes in their own org and pulls down all of the metadata to their IDE.
- A package XML file is set up and maintained (constantly) that specifies which metadata is being created by your project.
- Changes are checked into SVN.
- Manual changes (i.e., not supported by metadata) are tracked in a shared Google doc (the audit trail CSV can help as well, but the Google doc is the official record).
- Developers update from SVN to get each other’s changes. They need to be careful about the order of pulling down data from their org vs. updating from svn.
- Developers will need to be very comfortable with the metadata XML file formats.
In theory, what is kept in SVN is just the changes that the developers make so that you could easily apply those changes to any of your sandboxes, rebaseline from production, look at revision history and reverse merge.
Also keep a separate repo of data:
- Reference data that is needed to set up org: Think custom settings, portal accounts, product/event reference data, etc. This is data that would be considered a part of the installation or your org and/or project.
- Test data that can be used to populate an org: Useful for testing, getting orgs set up / recreated for development.
Set up CI (Jenkins) to automate builds on check ins and/or nightly if the manual problems are an issue:
- Jenkins uses the ant migration tool to push changes.
- All unit tests are run
- Jenkins w/ Selenium plug-in runs suite of Selenium tests.
Reality…
There were issues with setting this up.
- There were bugs in the metadata that prevented us from automating pushes.
- Metadata XML files frequently got “whacked” or out of synch.
- Developer’s spent an inordinate amount of time resolving merge conflicts.
- Bugs in Salesforce and the IDE such as the IDE mistakenly marking files as changed.
- Extra overhead of needing to know the metadata XML file format. All of that makes it cost prohibitive to set up development environments like this for short term (e.g., 3-6 sprints) projects.
- Frequently contract work is done on existing orgs with existing problems.
We’ve ended up developing in a less desirable way but it gets the job done and we honestly haven’t had any real issues with it.
- Developers all work in the same office and/or have excellent communication with each other w/in the project. Each developer has their own login credentials, so that who changed what can be tracked.
- One dev sandbox. All developers work in it. Unit test job (in Apex) is set up to run periodically.
- Jenkins job that runs nightly to back up the sandbox to git, in case someone accidentally refreshes it.
- One QA sandbox. Change sets are periodically pushed to the QA env for the QA team to do their testing in a stable and controlled environment.
- One UA sandbox. Change sets are pushed here periodically (e.g., end of sprint) for the users to test.
- One staging sandbox. Change sets are pushed here in preparation for production deployments.
- The audit log CSV is used to track who made what changes and assist in change set construction when the Force.com IDE or ant migration tool isn’t used.
- Data load CSVs maintained in a central repo.
All that being said, if I were working on longer term projects (2+ yrs), maintaining my own org, or maintaining an AppExchange app I would recommend trying to set up and maintain something more like the theoretical best practice.
Final remarks…
Remember that you can have more than one project in an Eclipse workspace. Separate the code and perhaps pages and other objects that are being touched frequently into their own project. Smaller projects refresh (and build) much more quickly. The migration toolkit (which uses ANT) is much faster than the IDE and can handle much larger datasets.
I need to stress that Communication is the key. Talk to each other, and make sure everyone is in the same page, whether about the good practices and strategies, or the actual changes in the code.
If you have other tips on the subject, or just want to share your experience with me, please send me an e-mail. Let’s discuss!