Salesforce Application Lifecycle Management for ISVs

The purpose of this article is to describe how Flosum can be used by ISV partners for Salesforce application lifecycle management functions.

Salesforce had a vision to provide easy-to-use, rich user experience for applications like amazon.com and eBay to enterprise customers. Flosum has a similar vision to make release management easy-to-use for Salesforce ISV partners.

Vision and Roadmap:

Flosum is a complete requirements to retirement application. It integrates with requirements applications, such as Salesforce’s Agile Accelerator, to capture requirements, sprint cycles, burn rates, etc.

The footprint encompasses the following steps:

Flosum provides complete environment management to define the owner of various sandboxes, refresh schedules, etc.

Flosum provides an easy-to-use, complete, robust version control system. The version control system supports sophisticated application development workflows, including branching and merging, to ensure developers are productive and accountable for every change that is made. The version control within Flosum is much easier and more powerful to use and built specifically for Salesforce.

Differences in Release Management Between a Typical Salesforce Customer and an ISV Partner:

The release management for a typical Salesforce customer is a little different than how the release management for the ISV partner is done. The differences are due to the following factors:

• The “ultimate destination” for source code for a typical Salesforce customer is production organization. For the ISV partner, the packaging organization could be considered as the production organization. If the code is working properly in the production organization, a Salesforce customer is quite happy. However, that is not the same for an ISV vendor. The ISV vendor needs to perform more packaging tests before giving the package to the customer.
• For a Salesforce customer, the source code written by the customer is not encrypted in the production organization. When the sandbox organization is refreshed, the source code is also available in the sandbox environment. However, for an ISV partner, the source code cannot be retrieved from the packaging organization via Metadata APIs or any other approach. The only way to retrieve the code is to do it manually.

Application Lifecycle Management Processes:

The application lifecycle management for an ISV vendor can be described in the following phases:

• Requirements planning
• Release management to test the code
• Release management to test the packaging

Requirements planning:

ISV partners need an application to manage the business requirements, assign the requirements to developers, manage the Sprint cycles, burn rates, etc. Most ISV partners either use a homegrown application or use off-the-shelf applications such as Jira or Agile Accelerator. Salesforce has introduced the requirements management application – Agile Accelerator – to help customers manage their business requirement.

Environment Management:

Once the requirements are captured, Flosum helps you manage the mining strategy for your development organization. Flosum customers can expand the out-of-the-box application to capture attributes such as the names of various sandboxes, purpose of sandbox, the date the sandbox was refreshed, etc.

Code Promotion:

To test the code, the process does not really differ much from a typical customer other than the last step.

The major problem with all Salesforce ISV packaging organizations is that all the code is kept in an encrypted state. Therefore, there is no way to retrieve that code from the packaging organization by using any automated tools. Hence, we recommend deploying the latest code in a developer organization before the code is deployed in the packaging organization. This will ensure that you have an organization from which you can replicate the source quote for your development and testing purposes.

The actual code promotion path for a typical Salesforce customer looks like:

The actual code promotion path for a typical ISV customer will look like:

Continuous Integration and Continuous Testing:

On each commit to the version control, Flosum also fires off Continuous Integration and Continuous Testing processes. All the changes committed are submitted for a build. At the end of the build, all the test cases are run to ensure that there are no failures. If there is any error, the entire team is notified.

Testing the packaging:

Even after the code is completely tested and deployed in the packaging organization, it does not mean that the package is ready to be delivered to the customer. For example, the code could work for new customers, but not work for customers who need to be upgraded.

The ISV partner should perform the following tests beforehand to ensure that the package is production quality before it is delivered to the customer.

The tests should at least include the following:

• Testing the update on all Versions which are currently used by the customer
• Testing the update on all the various editions that your package is supported on
• Testing the trial force templates
• Creating and testing test drive organizations

Next Steps

• Explore Flosum on the Salesforce AppExchange
• Discover why 98% customers would recommend Flosum Solution
• Read Flosum customer reviews on G2
• Download Free eBook ” Why 80% Salesforce DevOps Initiatives Fail”
• Try a Free Demo of the #1 Salesforce Release Management Software
• Follow us on LinkedIn and Twitter