In this blog post I will explain the process we use to prepare Salesforce developer orgs so that the orgs can be used easily with the tools and techniques that I will discuss in subsequent posts. Rather than preparing developer orgs as and when needed, we spent some time preparing a collection of 30 developer orgs that are reserved for use by developers and recycled when not needed.
Why prepare and clean Salesforce developer orgs?
When you create a developer org it comes with some sample code and applications and a default configuration. It is important if we are going to use multiple developer orgs that they are all the same so the code from each is compatible. The simplest way to achieve this is to remove all of the samples and configure the options to match your requirements. If the samples are not removed then the sample code may unintentionally become a dependency of your code or package. Similarly if the the settings between 2 developer orgs differ the code may not be compatible when reintegrating code from the orgs.
Ant scripts are used to achieve the steps involved where possible because we will want to repeat the steps for other tasks that we will discuss in later blog posts.
What is involved?
- Create a New Developer Org
- Request Org Modifications
- Set Org Namespace
- Set Password Policy
- Configure Org Settings
- Retrieve Org Settings
- Set IP Address(es) Access
- Configure other Settings
- Remove Sample Code
- Create Developer Users
Why do it advance advance?
As I mentioned in the Dreamforce session, one of the most frustrating delays we encountered during development was the time it took to prepare a Salesforce Org to work with. There are a number of steps required to setup a developer org and each step takes time. The steps involved include:
- Request a new developer org either through the Partner Portal or your Salesforce Environment Hub
- 5 – 15 mins
- Raise cases for any extra features needed e.g. enable Cascade Delete, increase Apex Character Limit etc
- 4 – 24 hours (depending on support contract)
- Set Org Namespace
- 5 mins
- Configure Org Settings
- 5 mins
- Remove default / sample code provided by Salesforce
- 10 – 30 mins
- Create User Accounts
- 5 mins or more
This means that preparing a new developer org can take from 4.5 hours up to 25 hours and that is not practical for day to day development tasks so the best approach is to create and prepare multiple developer orgs that can be uses when needed without a delay. If the orgs are created and prepared together the time delay is minimised as all the above steps can be done concurrently for each org.
Creating a Developer Org
Requesting a new developer org is very simple and can be done either by using the Environment Hub as explained here or by logging into the Partner Portal and clicking on the “create a test org” button. If you are not a Salesforce partner and do not have access to the Environment Hub or Partner Portal, you can create an org from the free trial page. When you request an org you will get an email with a link that will allow you to set a password for your login. My preference is to use the Environment Hub as it will maintain the list of orgs you have and will be useful for managing orgs (I mentioned an org reservation system we use in my Dreamforce session but I will elaborate in a future blog post).
Request Org Modifications
Once you have logged into your new developer org you should note the org ID, this can be found in Setup, Company Profile > Company Information:
You can then raise cases on the Partner Portal to modify the org as needed. Multi Currency, Cascade Delete and Apex Character limits are just a few of the modifications we request when creating new orgs but you will need to figure out which changes, if any, are needed for your development projects.
Set Org Namespace
At Altify we build Managed Packages to make our software available and these packages are identified by a Salesforce Namespace which is unique to the packaging org for our application. However we develop our package outside of this org so that we have branched / isolated feature development. If the orgs we use for development did not have a namespace defined it would be difficult to add code code in these orgs to the packaging org as the prefixes would be missing. By setting a unique namespace in each of our development orgs we will have a simple token that we can substitute globally when moving code between orgs. We would recommend using numbered Namespaces as the intention is to reuse the orgs in future e.g. ABCDEV1, ABCDEV2,… , just make sure the Namespaces are unique to you or your company.
To set the Namespace for your Developer Org click ‘Setup, Create > Packages’ and click ‘Edit’:
Then enter a Namespace and check to see if it is available, if it is click ‘Review My Selections’
Finally click ‘Save’ once you are happy with the selected Namespace, for this example we are using TASBLOG.
Note that although we created a Namespace we did not create a package because this can restrict the ability to empty / undeploy the org and recycle it for other future development work.
Set Password Policy
While I won’t share our password policy we have some preferences for our passwords i.e. what type of password is acceptable, how long is a password valid and can old passwords be reused. If you have a preference or requirement for password policies you should set them in your new org.
To do this go to Password Policy (Setup, Security Controls > Password Policies) and choose the settings you want and click Save.
Configure Org Settings
The majority of your Developer Org settings can be managed using the Migration Tools. Before modifying any settings we need to retrieve the current configuration which can be done with the retrieve.org.settings target in the following build.xml:
You may have noticed that this target uses a Migration Tools task called sf:bulkRetrieve rather than the sf:retrieve we used in the last blog post. The tasks are similar but the bulk task will retrieve all metadata for the type specified in the attribute metadataType unlike the standard retrieve which downloads the metadata specified in a package.xml file.
In order to run this target you will need a propery file called build.properties that contains 2 properties sf.username and sf.password just like the one we used in the previous blog post. However we have not set the IP Address access yet you will need to append the Security Token to your password in the properties file. To receive you Security Token in an email click Your Name > My Settings:
Then click Personal > Reset My Security Token, Reset My Security Token:
Now when you run the ant target retrieve.org.settings it will create a directory called settings and download the org metadata files for the org settings. You should browse through the metadata files to see what settings can be configured.
To deploy any changes you make to the metadata files you should use the following target which you should add to your build.xml file:
Although there is a metadata file for Security that contains a passwordPolicy element I have not been able to set the Password Policies via the Migration Tools as it fails with errors which is why I have detailed the manual process above. Hopefully in future releases this will be fixed.
Configure Network Access to allow know IP address access
You need to ensure that all developers who need to use the org can access it so you will need to whitelist IP addresses for those developers. The IP addresses will typically be the address for your office(s) or home. If you don’t know your IP address you can get it the What is My IP site. Often you will need to add multiple IP Addresses or IP Address Ranges and these can be added to the Security.settings file in the networkAccess element as follows:
The a.sinlge.ip.address, ip.address.range.start and ip.address.range.end values in the above example are just for illustrative purposes and you should replace these with the actual IP Address(es) you want to have access. You can add as many or as few of these ipRanges elements as you need.
When you execute the deploy.org.settings the specified IP Addresses and ranges will be whitelisted by the org so any developers on those IP Addresses can use the org if they have a login.
Remove Sample Code
Previously Salesforce developer orgs used to include more samples such as a “Start Here” page and a sample application but there appears to be less content by default in the orgs more recently so there is not as much to remove anymore. The items we currently need to remove are the following:
- Assignment Rules
- Custom Fields
- Custom Layouts
- Custom Profiles
- Escalation Rules
- Home Page Layouts
- Quick Actions
- Remote Site Settings
- Roles
Most of this content can be removed using the undeploy technique that was explained in part 1 of this blog series. Unfortunately this is not the case for all of the items. If you try to remove all this content with a destructiveChanges.xml (like the one below) specifying all the items it will fail for a few reasons.
Any Custom Fields that are referenced in Custom Links cannot be removed so the Custom Links have to be removed or you will get an error like the following:
objects/Opportunity.object (Opportunity.TrackingNumber__c) — Error: This custom field is referenced elsewhere in salesforce.com. : Custom Links.
Also the roles will fail to undeploy because the undeploy cannot handle the hierarchy between roles and will give a error like the following:
roles/VPNorthAmericanSales.role — Error: Your attempt to delete the role VP, North American Sales could not be completed because users are currently assigned to that role or at least one role reports to that role.: Role: Director, Channel Sales, Role: Director, Direct Sales
To overcome the issue with Custom Fields we can just remove the Custom Links from the Layouts. To do this we need to retrieve the pages, modify the metadata to remove the Custom Links and deploy back to the org. We can achieve this with the following ant target in the build.xml:
Notice that there is a new target called remove.custom.links and there is a new depends attribute added to the undeploy target that we used in the previous blog post example.
The new target creates a temporary directory and then uses the Salesforce Migration Tools to retrieve the layouts. Again we are using the sf:bulkRetrieve task for the retrieve part as we want all of the layouts downloaded. The batchSize of 100 is used to ensure that all of the layouts are retrieved in a single attempt so that the package.xml we will be left with will be complete, if batching is used the package.xml gets overwritten on each batch run so it would only contain the content of the last batch when the job completes.
Now the layout metadata is available, it’s needs to be updated to remove the Custom Links and this can be done with the following XSLT:
The XSLT file should be saved in a new directory called xslt in a file called remove.custom.links.xslt. The xslt task in the remove.custom.links target (below) will apply this XSLT on the files specified in the fileset nested within it. If any layout metadata files are found to have been modified by this transform then they will be deployed which will remove the Custom Links from those layouts.
By adding the new target as a dependency to the the undeploy target it will execute the remove.custom.links before attempting the undeploy. Notice also that we are using the namespace ant:if in the build.xml to allow us use the conditional attributes (only available in ant 1.9.1+) which allows us to only execute the deploy if files are modified.
However, this only solves half of the problem because we still can undeploy the Roles as they have hierarchy. Applying an almost identical solution will remove the Role Hierarchy. The following XLST should be saved as remove.role.hierarchy.xslt in the xslt directory created earlier:
A similar target to the one for layouts is then added to build.xml and added as a dependency to the undeploy target:
Now when we execute the undeploy target it will run successfully because it will run the target to fix the Custom Links, then target to remove the Role Hierarchy which will mean there are no obstructions when it runs the undeploy process.
Create Developer Users
Once all the above steps have been completed the is ready for use and we just need to give each of the developers a user account so they can log into the org. The can be done in Setup, Manage Users > Users, Add Multiple Users:
When creating users you will want to select a Salesforce licence and a System Administrator profile so that developers can modify code the org. You can use this to create multiple users but the screenshot below only show input for a single user because there is only 1 Salesforce licence left in this org.
Conclusion
By now we should have an org or a collection of orgs that are clean of sample code and are configured and ready for development. In the next post we will look at some more advanced used of the Migration Tools and some other tools we have found useful. Once those tools are explained I will demonstrate how to recycle developer orgs by removing all content and resetting the configuration using scripts.