Latest news, useful features and tips for your Salesforce

Why is it important to develop a solid workflow?

September 30, 2015

At CodeSWAT we pay significant attention to quality of products, codes and the way we deliver them to our customers. In this blog post we would like to talk about quality and how quality depends on the right deployment process. One of the major issue is how to build a solid workflow without losing quality? Let’s figure it out!

At What Workflow Stages can you lose Quality?

In this example we will highlight how important it is to build a thorough deployment process and how it may influence in the testing process, and thus the quality of the final code.

What is specific about incomplete workflow structure?

There is nothing better than customer’s experience, isn’t it? We would like to consider the very specific example. What challenges you may face with, without enough experience in Salesforce and why it’s necessary to leave complicated IT tasks to experienced guys.

Here is where we draw attention to the Deployment process with the chaotic structure:

1. Developers merge code into wip (work in progress) branch.

2. Developers test code on their own orgs (Dev Orgs). The first challenge comes up: when deploying code on staging it comes to it as separate commits.

3. Then Code on Staging sandbox are not the same as on Development and Production envs. that is why testing on Staging is not efficient.

4. Finally, code deploys from different places to Production and it’s very risky from QA prospective. Why you may ask? We don’t have a stable code which was completely tested before deployment and any testing doesn’t provide information about real situation.

Workflow structure

How to reduce low quality on a project and build well structured workflow?

Taking into account risks and quality to be a major factor on this project the CodeSWAT team suggest the following process:
1. When development says that they finished sprint or some planned features, the code should be forked into release_candidate branch (Step 1).
2. Whole release_candidate branch should be deployed on UAT/Staging sandbox (Step 2).
3. On Staging QA/PMs/BA do new features testing, regression testing.
4. All bug fixes should be done only in release_candidate branch (Step 3).
5. QA do sign-off to Production in case we reach all quality objectives.
6. Then tested code from release_candidate branch should be deployed to Production (Step 4).
7. If everything works correct on the Production, release_candidate branch should be merged into Development branch (Step 5)

^98534C5669B13F369DA549B7B2144A5D7636160F37FB05A47C^pimgpsh_fullsize_distr

CodeSWAT QA department always ensures that the product is consistent with the functional and nonfunctional requirements. CodeSWAT testing engineers strictly control how well development processes are placed and whether they are effective or not for each project. Do you like our workflow model? Wanna try? Please, don’t hesitate and write us back at marketing@codeswat.com