5 Steps For Salesforce App Development Lifecycle

Software development is not an easy task and when we have to implement the different software development methodologies it becomes all the more complex. Cloud and cloud based systems have captivated the minds of the people these days. So developing a cloud based system in a cloud environment is yet another challenging task. Salesforce Development Lifecycle is like a software developed on cloud, tested on cloud and deployed on the cloud environment.

Force.com is the Salesforce Development Environment. It is built using Eclipse hence it can be effortlessly integrated by using a plugin. It is strongly equipped with Apex, Visualforce and metadata components making it eligible for developing Force.com Apps. Data is saved on local file system and the developers migrate the files to source control repository makes the changes and it is fed into the system again. For source control most developers use Git or SVN.

In a development process, a number of actors are involved who handle different aspects of software development. The most common actors involved in this life cycle are as follows:

Product Manager- He is responsible for finalizing the business requirements.

Release Manager- Coordinates release schedule.

Software Developer- Does the main coding , producing deliverables.

Quality Analyst- Test and confirm various features.

Trainer.

The following steps will very clearly demonstrate the entire Salesforce Development Lifecycle:

1. Setting Up Source Control Repository: It is always beneficial in the long run from a development point of view to have a separate Git repository for every project, with a default branch acting as the Master branch. It is will be more suited to the purpose of storing the production metadata in the master branch.

As discussed above there are a number of actors involved during the entire lifecycle of the development. Release Manager helps to create entirely different branches for different features which are supposedly handled by different developers. He/She also helps in creating package.xml manifest while also using the same to populate the Master Branch with Metadata and very rightfully uses Force.com Migration to migrate all the data.

2. Development Phase: There is this concept of sandboxes in Salesforce. Sandboxes are totally isolated from your Salesforce production, so it implies that the operations that you perform in your sandboxes don’t affect your main Salesforce production enterprise, and vice versa. The developers start coding in their own sandboxes.

They use Force.com IDE to make connection with their sandboxes and thereby retrieve the matadata from sandbox to the IDE. They do the necessary coding and after performing initial level of unit testing they commit the code to the Git repository.

For subsequent development this fresh code that has been committed is migrated to their sandboxes and they continue with further development. After completion commit the latest development to the repository.

But there can be a possibility that two or more people are working on the same code, hence they definitely have to check for any possible conflicts before committing their code.

3. Testing: As the normal software development lifecycle flows, so is this here in this case. After the development is over it is time for testing. Similar to the developers the testers or QAs also create their own sandboxes and migrate the code to be tested from the repository to their sandboxes.

Sometimes the QA might be assigned with the task of testing only a particular feature. In such a case they use Partial Copy Sandboxes. They deploy only selected features and allows specialized testing of the app features.

QA members can also share their sandboxes if situation demands for a more thorough testing of vital and crucial features but it largely depends on the organization’s workflow pattern.However any changes suggested at this level would take it back to the prior phase of development.

4. Acceptance Testing: After this level of testing is completed it goes for further user acceptance testing. Apart from the QAs and tester the developers, product manager and other parties concerned will perform the final level of testing.

The release manager at first creates partial sandboxes for testing and the same are used by the product managers to carry out the ad hoc testing. And then he/she prepares the final presentation for the end users or clients. These sandboxes can also be used by the trainers of the company to prepare manuals for the trainees. Again in this phase if any further changes are suggested it goes back to the development phase to inculcate the necessary changes.

5. Product Release: The last phase is all about performance testing. This testing is performed on intermediate sandboxes which unlike partial sandboxes has all the features of the app.The testing team performs rigorous testing and regression testing. After it passes all levels of testing then it is successfully deployed in the production environment.

However it is always expected that some or the other important changes will definitely crop up after the final deployment. These end moment changes are handled in the patch releases. Patch cycle has a lifecycle of it’s own but it is quite faster process than the normal development cycle.