Updating metadata and making configuration changes in a Salesforce Production environment is risky.

The best practise is to make the changes in your sandbox/development organisation which is related to your Production environment. There you can implement, check for conflicts and test that the requirements are met. The software development life cycle (SDLC) shows the deployment phase AFTER the implementing and testing phases, how is this possible if you update directly into Production?

Salesforce offers different types of Sandbox/Development environments, depending on your licensing.

Developer Sandbox

Developer sandboxes are intended for coding and testing in an isolated environment. These environments include a copy of your production organization’s configuration (metadata).

Developer Pro Sandbox

Developer Pro sandboxes are intended for coding and testing in an isolated environment. These environments include a copy of your production organization’s configuration (metadata). They have a larger storage limit than Developer sandboxes. The larger limit allows for more robust test data sets and enables this environment to handle more development and quality assurance tasks.

Partial Copy Sandbox

Partial Copy sandboxes are intended to be used as testing environments. These environments can be used for quality assurance tasks such as user acceptance testing, integration testing, and training. These environments include a copy of your production organization’s configuration (metadata), and a subset of your production data as defined by a sandbox template.

Full Sandbox

Full sandboxes are intended to be used as testing environments. Only Full sandboxes support performance testing, load testing, and staging. These environments are a replica of your production organization, including all data—for example, object records and attachments—and metadata. The length of the refresh interval makes it difficult to use Full sandboxes for development.

There are many benefits to utilising the sandbox, especially for Salesforce environments that contain a lot of code.

Even simple changes to configuration or meta-data can result in negative affects to your existing code or workflows, so it makes sense to test these changes in a separate environment, away from your live data. Sandboxes also ensure that your testing classes – which are the coded scenarios testing your actual code – are valid and checking the majority of your code for logical errors. Once development of the code is completed and testing classes are adequate, it is time for user acceptance testing and regression testing. Users from the business should be checking within the sandbox itself that the requirements have been met and there are no regression issues – that is, nothing that was already existing in the org has been broken due to the new changes.

Once the UAT has been signed off, its deployment time. Deployment includes validation which is a final check to ensure that the code, new config and test classes don’t clash with the production org. If you have kept your sandbox in sync with the production environment (ie not made updates to Production that haven’t been either deployed from Sandbox or replicated in Sandbox), there should be no problems. But if there are errors found, its always best they are found before deploying new functionality than deploying blind. If you have not updated your sandbox for a while, it is easy to refresh from the production, but take caution that it will overwrite any pending development work in the existing sandbox.

So what happens when you have more than one developer/team of developers working simultaneously? This is where things can get tricky.

Multiple Devs

There is no locking mechanism to ensure separate developers are not simultaneously updating the same code or metadata. If the developers are using external software such as Eclipse IDE for Java Developers, they run the risk of overwriting all changes made since they last refreshed from the server every time they hit save. So with more than one developer, it is essential for a multi-developer plan to be in place. It must cover who is working on what components, schedule of work and deadlines, solution designs, deployment plans and a communication plan. There needs to be clear rules on who is responsible for the different aspects and who will be responsible after deployment for investigation of issues. Even if the functionality of the work seems separate, they still may be touching shared resources or metadata, creating conflicts and/or overwrites.

If it is imperative that there are multiple developers working in the same environment, it should be carefully considered if the work can be done asynchronously rather than simultaneously. Working autonomously but simultaneously runs a great risk and will most likely increase the development time required in the long run , having to investigate issues resulting from regression testing thus increasing costs. There must be careful consideration for the setup of sandbox environments. Having two developers work within the same sandbox environment is scary. Multiple sandboxes can be implemented with additional licensing and configuration of these sandboxes can help avoid some of the issues I have already mentioned. A staging environment where two or more development sandboxes can deploy to for testing is an ideal generic solution. Developers can test their new and existing functionality within the staging environment for conflicts and the business can perform their user acceptance testing before it impacts the live data in production environment. But it’s all about taking the time BEFORE you start developing to understand how to manage the risks, so documenting a plan is the best way to start.