Salesforce is a very flexible platform to develop on. The complexity of the development landscape differs based on how many administrators/developers are involved, and the scenario (project/break-fix). When you have a single administrator responsible for your Salesforce org you might get away with a simple landscape with just a Production and Full Sandbox. However, if you have a scenario where you have multiple people working on the system (or) you have distributed delivery with near share and/or offshore teams, then this simple landscape will not work. You need a landscape that is easy to develop, test and promote changes through, with the least amount of disruption to end users and the development team. In this post I'm going to explore a simple landscape scenario with concurrent development on Salesforce with multiple developers. I call this a simple landscape because it does not cover the use of a Source Control System. I'll cover that on another blog post.
If you want to read through the odious yet fascinating Salesforce development lifecycle, with suggestions on different scenarios and their landscapes click here.
If you want to read through the odious yet fascinating Salesforce development lifecycle, with suggestions on different scenarios and their landscapes click here.
Prepare your sandboxes
Before we discuss the landscape we need to decide on the sandboxes in your landscape. A simple landscape will need to have a Quality, Integration and Development systems. The number of development systems will depend on the number of developers working on the system.
The sandboxes have different limitations on refresh intervals and storage. Click here to read about them. A Full sandbox would be an ideal Quality system. In the absence of another Full Sandbox, a Partial or Dev Pro sandbox could be used as an Integration system. A Partial, Developer Pro or Developer sandboxes could be used as a Development system.
The Developer Pro and Developer sandboxes have a severe storage limitation compared to the other sandboxes, which forces us to select data that is most useful to test different scenarios while developing. There is no standard way of exporting and importing data into these developer sandboxes. Read this discussion for some creative ideas. My suggestion is to script the export and import process with an ETL tool (if you have one), since it's repeatable and
No comments:
Post a Comment