Red Argyle Logo

Patterns
The Salesforce Blog with Tailored Goodness

The (Newly Improved!) Red Argyle Approach to Release Management and Deployment: Part I

At Red Argyle, we have been working on improving our QA practices. Two of the biggest processes we have improved upon are release management and deployment in Salesforce. As a result of these new/updated processes, we have been efficiently developing and delivering new requirements and functionality to our clients, which means we couldn’t imagine going back to our old ways. After all, we need to evolve just as quickly as technology. In this post, I will be briefly describing how we handle releases of applications and versions of those apps.

Release Management with JIRA

Our team developed a process surrounding release management to give us a quick and painless way of determining what and when we delivered without having to dig through documents or JIRA, which we use for project management. Now when a client asks us if we delivered a requirement or to revert to a previous release, we can quickly determine when it was released and what would be affected if we reverted, even if the team member(s) who worked on the project are unavailable for any reason.

Jira Versions

 

 

 

 

 

 

 

 

 

 

 

I mentioned previously that we use JIRA for project management, and wouldn’t you know it, JIRA has built-in version management as well. This is great for planning, assigning, and releasing versions. Now after each release, we export the issues from that release and the necessary details into a changelog, which is our ever-expanding and updating document shared between our team and the client. The changelog is just what we needed to give both our team and the client a brief, but descriptive view of all of the work that has taken place in their Salesforce org.

The documentation created during this process can also help introduce new players to the project from both the client side and our team at any phase. When introducing a new person to a project, you don’t want to overwhelm them, so we came up with an AppDoc for situations like this. It serves as a one-stop shop for everything the new person needs to know about the project in 15 minutes or less, including the changelog, so they can see how the application has progressed. Since the changelog is updated after each release, being included in the AppDoc will serve as a hint to the QA team that something might need to be added or updated to ensure “everything you need to know” is present.

Another process we recently put in place is related to deployment in Salesforce. One of our bigger projects that required a lot of quick releases had given us some trouble with past deployments, so we decided to put a little bit of structure around a process to handle our more challenging projects moving forward. Check in next week to read my blog post that gives a walk-through of the improved deployment process we have in place now, which has helped us manage these types of extra-demanding projects.