When I work with our customers, I am frequently asked how to best handle changes with Visualforce in their production environment. I’ve noticed a trend that many companies do not have a deployment strategy at all, much less a formal and documented process. Whether your go-to strategy is configuration or customization, my hope is that you can begin to develop a simple deployment strategy after reading through this blog.
Where Do I Start?
Let’s start with the basics: Salesforce utilizes a development approach called the Software Development Lifecycle (SDLC). The SDLC is an approach that would have you design, build, and test new features and code within one or more sandboxes before deploying the changes into a production environment. When you are creating Visualforce pages, particularly pages that have Apex Extensions and Apex Controllers, you will need to be aware of Salesforce’s code coverage requirements. A minimum of 75% code coverage is required to deploy Apex code into a production environment. When deploying code, Apex tests will be run and all tests will need to pass without errors before the code can be deployed.
All of your Visualforce pages should be tracked or managed in some form of a Source Code Management System such as GitHub, Subversion, or SkyVisualEditor. These various platforms will allow your developers and administrators to build the necessary Visualforce pages and create “versions” of the page that reflect changes that occur to that page over time. Ultimately, this means that if a page update takes place and the admin or developer can’t figure out why it isn’t working properly, they can always revert back to the previous working version of the page to have in production until the issues are resolved.
What Is A Visualforce Deployment Strategy?
When I use the phrase Visualforce deployment strategy, I am simply referring to a process that is followed to ensure that changes to production are handled properly. Most companies that I see attempt to do everything directly in production environments and use Sandboxes for larger projects. Every solid deployment strategy or methodology that I’ve encountered over the years will contain the following steps:
1. Plan 2. Create 3. Document 4. Test 5. Deploy 6. Test again
Depending on the strategy or methodology that you’ve researched, they may call the different parts other names or they might be done in a different order, but at the end of the day, they still exist for people to do. Let’s take a deeper look at what each of these means for the admin or developer.
#1: Plan
Identify how your team is going to plan changes within an environment. Do you use a platform like JIRA to handle all of the change requests that come in? Do you have some form of Excel document to contain the requests? Are you using a custom object in Salesforce to track changes? Which approach is best? Here is the dirty little secret about this: the best platform for change management is the one you will actually use. It really doesn’t matter how you go about planning your upcoming changes as long as you are able to look at the various requests and prioritize them properly.
I use a method called “PIE Score”. I don’t remember where I originally learned about this, but it essentially breaks each request into 3 categories and gives them a score to determine where it should fall in terms of priority.
P = Potential Impact I = Importance to Business E = Ease of Implementation
Each category is given a number between 1-100 and then the 3 numbers are averaged together to create that request’s PIE score. You can then rank the request based on the score to determine how things get implemented.
Remain consistent in whatever method you use to plan your changes. Planning is a vital part of creating a successful implementation of Salesforce long term.
#2: Create
This step is fairly simple! Design and build your Visualforce pages along with any Controllers and Extensions that are necessary to have everything operate as desired. You can use something like the Force.com IDE or SkyVisualEditor to build your Visualforce pages and Extensions, so just pick the right tool for the job and get to work.
When you are working in your Sandbox, I would highly recommend refreshing your Sandbox to properly reflect the production environment. This is particularly true for companies who tend to make custom objects, custom fields, workflows, validation rules, etc. directly within the production environment.
#3: Document
When a deployment strategy does exist, I find that this is most often the step that is left out. It is extremely important for the longevity of your Salesforce implementation that you document your changes. If you’ve ever joined a new company as their developer or administrator you will appreciate this wisdom. Walking into an environment where you have no idea what was implemented or why it was done this way can be extremely frustrating. It is like trying to untangle that string of Christmas lights every year…very frustrating.
Documenting the Visualforce deployments comes in a couple of forms. The first form is to document the code that is actually created. This is for the sanity of the developers who need to maintain it. Create comments throughout the code to provide a summary of what is taking place so that things can be quickly identified for future changes.
The 2nd form of documentation is a business document. Some form of documentation that explains the business level reasons for the changes, what changed, why the changes took place, what new features were added, how to access things, etc. Essentially, it will be a help and instruction manual for the administrators who manage Salesforce. Again, this is extremely helpful for the long term vision of how Salesforce is used.
#4: Test
Test all of the Visualforce and Apex features that will be expected by the users. Do your best to get all of the requirements and scenarios that the business users want so that proper tests can be created in the Sandbox. The more testing you can do on the backend of the process, the fewer issues you’ll find in step 6. If issues are found at this step, and there almost always are, then you’ll want to go back to a previous step in the process and begin to implement the changes to fix the issue. Test again once the issue has been resolved!
#5: Deploy
When working with a method like the SDLC, you will initially deploy your code from something like Force.com’s IDE or SkyVisualEditor into a Sandbox. Once you’ve finalized everything and are ready to deploy into a production environment, it is a good rule of thumb to use a Change Set to migrate your Visualforce and Apex code into production. You could use either tool to deploy directly into production, but the Change Sets allow you to also bring over other artifacts within Salesforce such as profile permission sets, triggers, workflow rules, validation rules, etc. Leverage the Change Sets to your advantage to keep a historical view of what has been deployed into that environment.
#6: Test Again
Once you’ve deployed into the production environment, you’ll want to ensure that things operate as expected. Test the features again to ensure things work as the user expects. If something isn’t working, then quickly remove the new Visualforce page and replace it with a previous working version. This will limit the frustration and downtime that users experience when changes occur.
When you are working with changes in the production environment, it can be very helpful to create a “maintenance window” where the users won’t be able to access certain parts of the platform. This will give you time to make a change and test the change without the user being negatively impacted by something that doesn’t properly work. Typically, Visualforce pages won’t cause major issues, but if the page doesn’t operate the way the user expects, it can be disruptive to their productivity or cause high frustrations with the new process. Allow yourself some time to get everything properly connected and tested before users start to play with the new features.
Summary
When designing Visualforce pages, it is wise to have a plan in place for how you handle deployments into your production environment. This is critical to the long-term success of your Salesforce team and your use of the Salesforce platform. A simple strategy will contain the following steps:
1. Plan 2. Create 3. Document 4. Test 5. Deploy 6. Test Again
Other strategies might contain more steps or sub-steps for each of those categories and that is perfectly fine. The best deployment strategy is the strategy that your team will actually use.
Comments