Quick Version Deployment of Salesforce Packages after UAT

Of all the Salesforce development process phases, the User Acceptance Testing (UAT) phase may just be the most fulfilling. It’s the phase where your team finds out whether their collaborative efforts have resulted in a release that will meet end-user expectations.

On the flip side, UAT can represent a frustrating endeavor when issues like overwriting and bottlenecking occur. Change management can be an inherently chaotic undertaking. When it comes to the fast pace of UAT change deployment, the result is product deployment delays and a stressful work environment.

The good news is UAT testing doesn’t have to be this way. Integrating Salesforce with smart management tools can make all the difference.

UAT and the end user

User testing reveals areas for improvement and underscores the elements that make your product come alive and provide usefulness.

The typical UAT process

The tester performs a series of tests to answer questions aimed at evaluating the user experience under various conditions. Ideally, these conditions line up with real-world scenarios as much as possible:

  1. Is it easy to launch the product?
  2. Are the controls intuitive?
  3. How long does it take to load different aspects?
  4. Can I use this product to complete my primary objective?
  5. Do I see unnecessary items that detract from the product?
  6. How does the overall experience feel?

In a way, the tester is trying to “break” the product by putting it through its paces. If it can stand up to every “what if” scenario the end user can throw at it, you can feel confident that you’re on the right track.

Each time changes are introduced, UAT should be conducted again for new insights about the user experience.

Common UAT issues

The typical UAT process can become quite cumbersome. Teams often limit development and testing to one or two sandboxes, which makes it challenging to unravel information about potential changes. Who did what, when, and why, all become difficult questions to resolve.

Even if your team does track change information, they will need to devote resources to a significant number of manual data-entry tasks, taking them away from their primary development duties.

When things go wrong, they can really go wrong.

“Code clobbering” is a real thing, as many Salesforce developers can attest. Team members can accidentally deploy conflicting changes or overwrite one another’s changes to an irreversible extent.

Mishaps like this are not uncommon when teams need to handle change management. When multiple team members start deploying changes into the same sandbox without a clear sense of each change’s dependency status, chaos is all but assured.

The result of these convoluted processes is lost productivity and the frustration of never being able to fully get a handle on the change deployment cycle.

UAT, ClickDeploy style

Because it integrates Continuous Integration (CI) technology with robust source control repositories like GitHub, the repetitive, manual steps involved with typical change deployment can be completed with a few clicks of the mouse.

Automated CI prompts the DevOps tool to deploy GitHub metadata from the UAT branch into the team’s collective UAT sandbox for further testing of the latest approved features.

The UAT change process with ClickDeploy works like this:

  1. The administrator or developer uses the ClickDeploy Git flow to submit a pull request against the UAT branch.
  2. ClickDeploy CI picks up the changes, and the incremental CI deploys the feature to the UAT environment.
  3. After the feature has gone through UAT and has been accepted, the administrator or developer submits a second pull targeting the master branch.
  4. ClickDeploy sends notifications to designated team leads for final approval.
  5. Changes are queued up in the master branch, ready for production deployments.
  6. Deployment can happen by webhook, scheduling, or manually.

The ClickDeploy process is more straightforward, more accurate, and much quicker. With ClickDeploy, CI jobs are set as incremental builds that limit changes since the last successful build instead of deploying the entire branch. This method is faster and adds a safeguard against the risk of overwriting unrelated changes in production.

From here, team members can clone deployments, apply new changes to the master, and quickly release them to production.

ClickDeploy allows you to handle deployment at a designated time or after UAT has been completed. What does this mean for your process? First off, it means no more months-long releases. You can release features daily or as soon as they are accepted in UAT.

ClickDeploy is faster (and better)

The usual workflow steps (pull request, code review, merge with the master) are automated, speeding up the process, and reducing opportunities for introducing bugs and inaccuracies.

When it’s time to initiate a new deployment, team members can quickly repeat this process free from the fear of overwrites.

Along the way, team members can easily track the status of their contributions to the project and move on to other development tasks.

Try ClickDeploy