Development process for enterprise Force.com applications

September 17, 2015

Development of Enterprise level applications is a complex process which includes many phases: requirement analysis, technical design, development, QA, Security testing, UAT, production deployment and support. In your particular case some phases might exist when other ones will be excluded, but one phase would be exist anyway. It’s a development phase which might be infinite complicated. I have been involved to many enterprise projects on Salesforce.com platform and as a result I have formed the following process flow especially for such projects.

Below you can find a common development process for Force.com platform

So, on the diagram above you can see that each developer works on their own sandbox(or Developer Edition). This’s a must have practice for your project. Many times I saw a real paint in teams which didn’t follow this simple rule. The first trouble will be a fact that developers can’t working on a different tasks simultaneously because they can override they changes in the environment. Using a version control is a extremely needed for success project. You can find many options on the AppExchange which provide a metadata backup functionality. In the most case it’s a pretty good and simple solutions but really version control provides much more convenient and flexible way to manage your code and project metadata. I prefer Git but also have experience with svn and tfs. If you do not use such tools I highly recommend to start using it ASAP. The next step is to configure Continuous Integration (CI) server. I believe that you want to automate your processes as much as you can. Therefore I suggest to configure CI. CI lets you to configure a build automation for your environments. And first step is checking a repository stability. I assured that you want to be sure that your repository is stable and ready to deploy. Usually developers might broke repository by adding unstable code. Another issue with stability is forgetting necessary components. For example you can add apex class without meta file and it will broke the build. For detecting such commits you need to run auto-build after each commit. It’s a most common practice.

Salesforce team roles:

Development team leader / Technical architect – works on global architecture, converts requirements into technical tasks for development team, coordinate Lead developers, coordinates releases/deployments
Lead developer works on architecture of dedicated parts, performs code review, coordinates development and QA teams
Developer implements features, fixes bugs, implements automated test cases
QA team leader works on test architecture, coordinate development and QA team
Lead QA works on test documentation, prepares test suites, controls QAs
QA engineer performs test suites
Build engineer – responsible for a builds in all general environments, monitors version control stability

Principles and best practices:

Nobody have a direct access to CI sandbox exclude a build engineer, but all can see a build result on CI server. Sometime developers can quickly fix broken build to CI by performing some changes directly on sandbox. But after that they can forget to check in these changes into version control.
A build to CI sandbox is triggered by changes in a version control
QA team perform any verification only on QA sandbox. Developers does not perform any changes on this environment.
Build to QA sandbox runs by scheduler nightly. QA team have ability to request a build to QA sandbox anytime, for cases when significant things has been committed into version control and should be tested ASAP.
Development team provides a build to UAT sandbox at least once a week for testing by users. User feedback is incredible useful. Thus you need to start getting it ASAP.
Only product owner from business side can make a decision about a build stability. Also only this person can provide approval for build to SEC sandbox for security scan by third-party company.
Perform production builds on weekend. If you already have production org with active users you’d be happy to have some additional time without business user pressure in case of some bugs in production. Especially for regression bugs.
Have a roll-back plan. You need to have a prepared destructiveChanges.xml and a proved procedure of roll-back for any troubles.
Use a short sprints and deploy your code as often as possible.