You may have worked hard for many hours to implement Salesforce for your business operations. Then, suddenly, you find things are not working as expected. Deploying Salesforce is a considerable investment, and requires a fair amount of time and effort.
So, ultimately if you find that things are not working correctly, all the effort, time, and money go in vain. Again, fixing the issues may take another few days, so the vicious cycle continues.
How to mitigate the risk of deployment failure during Salesforce implementation? This is one question all business administrators who are planning to get on to Salesforce face, and here is the step by step approach to the smoother deployment of Salesforce.
Step #1. Write the unit tests for coverage and quality
To deploy the code to production, you must ensure a minimum of 75% coverage of code from the unit tests. Also, all the triggers should have some code coverage, too.
For this, you should first set a proper process rule at the very first point of the deployment project. It is also important to make sure that the developer who touches any piece of code should ensure it is completed and passes the tests at the desired percentage. You can set this desired percentage as a minimum of 85% or higher.
Following a consistent and steady unit test by meeting this expectation will ultimately make the entire project positive and successful. This ensures the below aspects too.
Promote a test-driven approach to development
The developers may be writing the tests first, even before writing the codes. This approach will further encourage a successful smaller method as well as appropriate class sizes. IT will enable easier testing as well as anytime helper class re-use.
It will help set up a solid and consistent expectation regarding code
Also, it will help with the estimates, as they must include time to prepare unit tests. One should run the tests at a minimal frequency like weekly, if not daily. If you find the class falls under the coverage limit of the test as specified, then it has to be diverted back to the developer for fixing.
On the final day, you may not get any errors
If the code coverage is less than 75%, then there is a possibility that you may fail ultimately on the last day of the development. There are many things to do on the day of production deployment without the need to deal with any error. You may get these works done at the time of the project iterations.
Step #2. Make all changes at a single place from beginning to end
While the deployments are happening, all changes in development should be referenced. You can use Eclipse in order to generate such changes, which is an ideal tool to compare destination orgs and source to list out the differences. However, this may not have all the changes in an org as there could be a lot of options for point and click options on Salesforce, which may not ultimately show up on Eclipse.
The Flosum.com deployment approach will track all such changes for the Org Wide Defaults, workflows, validation rules, approvals, etc. It is not a difficult task, but just maintaining a spreadsheet can do the trick. You may maintain the columns by marking the file names, the reason for changes, the developer who made the changes, and the time of deployment, etc.
An effective version control system for source code management can also give you a list of changes, but may not get you all parts of it. Alternatively, using Jira may also help track the changes and pull the list of changes at the time of deployment.
Step #3. Start with early deployments
If you are planning for deployment by keeping a certain timeframe or date in mind, then you may try to start at least one week in advance. For bigger organizations, it may take a minimum of two hours to finish a deployment as there are many tests to be run. When you find a few problems with each run of the test, it may ultimately eat up your time, and the ultimate process may run for days, if not weeks.
Always make use of the Validate button while you do deployment with the Change Sets and you can find the same options also exist in Eclipse. Deployment can be validated even without any deployment taking place at real-time. With this, the ultimate deployment may be ready to be run when the apt time comes.
Doing it this way will also give your team more confidence by seeing it ready to go and experiencing minimal flaws in running tests. They can immediately go with go-live activities too on getting it implemented properly.
Step #4. Take care of triggers
Triggers are actually so powerful but have to be done right.
- You must try to accommodate them well in order not to cause any governor errors. Say, for example, in a custom set of codes; you can do only 100 SQL queries. So, if you try to you trigger a query for records within a loop, then it may work out.
- Also, do the code reviews of the triggers. Such objects are very important that and you need to have an eye on them. APEX trigger coding needs a unique mindset than traditional programming. The developers need to nurture some best practices with triggers to understand it; however, these code reviews and programming sessions in a paired mode can be invaluable.
Step #5. Take care of the deployment and profiles
Salesforce profiles contain a lot of info and largely depend on objects which are their destination org during deployment. If a deployment can be further broken down into pieces, then it can simplify the entire deployment process. New fields and custom objects can be pushed initially as these are independent. Next, you can think of the code as well as the Visualforce pages following the validation rules, and finally the workflow and the approvals to be pushed. Profiles can be pushed at last so that all profile dependent objects fall in place.
Overall
Hope this step by step approach makes your deployment of Salesforce easier. However, this is just a directive guide to put some light into the deployment process, which in real-time requires a lot of expertise and practice to perform successfully.