Life cycle of a software development project is not very linear and is not very simple. Add to this new software development approaches like agile development methodology or waterfall development methodology and the things start to become complex. Now add in the fact that the software you are developing is being developed on cloud, tested on cloud, and finally deployed on cloud, the things start transforming from complex to confusing and at times incomprehensible. What I just said was a glimpse of the Salesforce development lifecycle, roughly.
In my previous post we talked about how a typical Salesforce project development lifecycle looks? What are the steps involved and the difference between Salesforce App Development and Salesforce Development? However I hinted that I would be explaining the lifecycle in a little bit more detail talking about the different actors involved in the process. We ‘ll do it now.
Actors Involved In Agile Salesforce Development Lifecycle
A typical Salesforce Development Lifecycle involves multiple actors. Many of them are specialist of one role and some have expertise in another. For example many project managers also work as release managers and many Developers also have expertise as trainers. But for the sake of this post I am going to define all actors.
Here are the typical actors involved in the lifecycle.
- Release manager – Coordinates release schedules with development team and client. Also in charge of source control systems.
- Product manager – Finalizes and coordinates the business requirements of the customization, features, and functionalities that are expected out of the final solution, and ensure that the final product is upto norms. Also in charge of final testing processes and development team coordination.
- Software developer
- Quality engineer
- Administrator
- Trainer
The Development Environment
Salesforce development environment known as Force.com IDE is a complete integrated Salesforce development setup that is fully equipped to develop Force.com apps having Apex, Visualforce, and metadata components. It is built using Eclipse as base and thus can be even integrated with it through a plugin. The most important thing to note about the environment is that all the data is saved on a local file system so that the developers have to migrate the changes to source control repository and then Salesforce platform. This can be done manually or through Eclipse plugin or through any other custom solution you are comfortable with. For source control most companies use GIT or SVN, but again it’s up to the developer to decide the tools.
For migration of code from source control to Salesforce.com, the best tool is the Force.com Migration Tool itself. The tool is a JAVA and Ant based command line tool that can easily transfer all your metadata from one platform to another. The tool can even be automated.
SFDC Lifecycle Step 1: Source Control Setup
Setting up the source control repository is usually the role of Release Manager. A good practice is to create separate GIT repository for every project with default branch of the repository acting as the Master branch. You will store all your production metadata in the Master branch.
The release manager then creates separate branches for separate features that would be handled by separate developers. The release manager is also responsible for creating package.xml manifest and use it to populate Master branch with metadata. As you may have guesses, the release manager would have to use Force.com Migration to actually migrate the data.
For large Salesforce development teams where a whole team is working on a single feature, each developer can clone the feature branch repository for their own work.
SFDC Lifecycle Step 2: Coding Beings
Development begins by the developers creating their separate sandboxes. These sandboxes usually contains a copy of main production app and all the associated Salesforce configuration information. As said earlier each developer has to clone their branch.
- The developers would have to use Force.com IDE to connect their sandboxes and retrieve all necessary metadata from sandbox to IDE.
- As they build up their assigned app features, they commit the code to git repository, after unit testing those features of course.
- Subsequent development steps by next developers can be performed by cloning the newly updated branch and migrating its data to their sandbox. So they get the newly update app feature that the first developer developed.
- The new developer builds on top of the previous features and then commit the developed app features to repository.
- Before committing the new developer may have to check the branch for updates to prevent conflicts.
SFDC Lifecycle Step 3: Testing
Testing of features by a QA expert is performed nearly like the development part. The QA creates their own sandbox, migrate the code from repository to sandbox and then test run the app.
For a more detailed testing, the QA specialist also deploys Partial Copy sandboxes. As the name suggests this type of sandbox only deploys select features and controlled data set. This allows for a more specialized testing of the app features.
If the situation arises, this testing sandboxes can also be shared with other QA team members for a more thorough testing. But it depends on the organization’s testing workflow of course.
Any changes required in the app will take it back to development step.
SFDC Lifecycle Step 4: User Acceptance Testing and Training
After the app passes all tests in the previous test phase, it is now ready for testing by development team, product manager and other interested parties.
- The release manager again create shared partial sandboxes for testing convenience.
- The product manager uses these sandboxes to perform ad-hoc testings and prepare a demo to be presented to the client or the team that would be using the app.
- These sandboxes are also used by trainers who prepare manuals and other training material based on the features.
- Any corrections pointed out by product manager, or trainer, or developer, would take the cycle back to the development phase.
SFDC Lifecycle Step 5: Final Release to Production
After all testing processes, the app is tested for performance. This testing is done in what is called an intermediate sandbox environment. This sandbox has all the production environment’s configurations and data. This is not a partial sandbox. It has all the features of the app. The QA team performs rigorous performance testing and final regression testing. Once the app passes all service level agreements, the final app is now deployed in the production environment.
Patch Releases
Even after the app is deployed there would still be needs for small hotfixes such as tweaking of a feature here, some bug fix there, or some new requirement for a minute change in the final deployment. These are all handled in patch releases.
Usually patch releases have a lifecycle of their own that kind of looks like the main production lifecycle but with faster processes.
Pratyush Kumar
