Cloud Sherpas. SALESFORCE Simplified Deployment Strategy Google Partner of the Year

Transcription

1 SALESFORCE Simplified Deployment Strategy Google Partner of the Year

2 Table of Contents SOFTWARE DEVELOPMENT LIFECYCLE 1 Simple development 1 A Simplified Software Development Lifecycle 2 Complex development 2 A Complex Software Development Lifecycle 3 THIRD PARTY SYSTEMS 4 Configuration changes in third-party systems 4 Configuration changes in middleware 4 Configuration changes in Salesforce 4 CONFIGURATION MANAGEMENT 5 External ID generation Cloud Inc. All Rights Reserved

3 SOFTWARE DEVELOPMENT LIFECYCLE Salesforce.com produces documented best practices and a recommended Software Development Lifecycle known as the SDLC. The SDLC requires developers to work in one or more sandboxes, promoting code to production only after a minimum level of successful test coverage has been achieved. A sandbox is an identical copy to the Production environment and they are available in three types: Configuration only (configuration and code only), Development (configuration and code, with additional development capabilities), and Full (configuration, code, and a complete copy of the data from Production). Sandboxes can be refreshed periodically to ensure a recent, exact copy for development, testing, and training. A minimum of 75% code coverage by line is required to deploy code to production. All tests must complete with no errors, and proper test design dictates that they also pass one or more assertions to demonstrate that the code is functioning as intended. These Unit Testing requirements do not apply to sandboxes, but best practice requires that unit tests written in the sandbox should succeed in Production with minimal configuration, with the possible exception of minor changes to enable Production side-effect. For this reason, a multi-stage testing and deployment process involving a current sandbox is critical. SIMPLE DEVELOPMENT Most small-to-medium projects are developed using a simplified SDLC model, in which all developers work in the same Salesforce sandbox. This model is appropriate when team members are co-located and the development tasks are limited to one or two developers per task. In such projects the coordination overhead is relatively low. Change Management in this such model is performed in team meetings, via , and using an issue tracking system such as Atlassian JIRA or a properly configured Salesforce org. Change Tracking is performed by periodically saving a copy of the shared Salesforce configuration and code to a source code management system such as GitHub or Subversion, usually with a reference to the issue or bug (in Atlassian JIRA) that prompted the change. A Simplified Software Development Lifecycle 2013 Cloud Inc. All Rights Reserved

4 A SIMPLIFIED SOFTWARE DEVELOPMENT LIFECYCLE 1. Create a fresh sandbox for development. In many projects, the development sandbox is a copy of the Legacy production org. 2. Commit to source control (JIRA) when development checkpoints or milestones are reached. 3. Create a deployment org. 4. Document the steps required to deploy from Development to Deployment, and perform a test deployment. Perform unit testing and basic functional testing in the Deployment org. a. Manual steps include configuring Sites, Portals, and other elements that cannot be migrated using the Salesforce.com-provided tools. b. Automatic steps include deploying objects, translations, labels, and development items (Triggers and Visualforce pages) using the Salesforce.com-provided deployment tools. c. Semi-automatic steps include configuring objects and fields to be deleted during the deployment process. 5. Once the deployment process is properly documented and the configuration and development are confirmed to pass unit and functional tests, create a new FULL sandbox (complete copy of Production, with data). 6. Follow the process from step 4 to deploy from Dev to Test, and perform Unit, Functional, and User Acceptance testing. 7. Follow the process from step 4 to deploy from Dev to Production, and perform Unit, Functional, and User Acceptance testing. Steps 3-6 may be repeated as many times as necessary to ensure that the deployment process is fully documented and that all tests are passed. If additional development is required to pass any tests or to support the deployment process, it may be done in the Development sandbox or the Deployment sandbox, in which case the deployment sandbox becomes the new Development sandbox and a new Deployment sandbox is created. It is critical that any issues encountered or fixed during deployment testing be tracked in the change control and change tracking systems. COMPLEX DEVELOPMENT An example Software Development Lifecycle (SDLC) 2013 Cloud Inc. All Rights Reserved

5 A COMPLEX SOFTWARE DEVELOPMENT LIFECYCLE 1. Create a fresh sandbox to act as a staging and consolidation area for multiple development tracks. At the same time, create one or more development sandboxes to serve each development track. 2. Commit to source control (JIRA) when development checkpoints or milestones are reached. 3. Document the steps required to deploy from source control to Development, and configure unattended (repeatable) processes for deployment using a continuous integration tool and/or the Force.com Ant deployment tool. Perform unit testing and basic functional testing in the Development org. a. Manual deployment steps include configuring Sites, Portals, and other elements that cannot be migrated using the Salesforce.com-provided tools. b. Automatic deployment steps include deploying objects, translations, labels, and development items (Triggers and Visualforce pages) using the Salesforce.com-provided deployment tools. c. Semi-automatic deployment steps include configuring objects and fields to be deleted during the deployment process. 4. Once the deployment process is properly documented and the configuration and development are confirmed to pass unit and functional tests, create a new Deployment sandbox (complete copy of production, without data). 5. Follow the documented deployment process to deploy the configuration and development in Source Control to the Deployment sandbox, and perform Unit, Functional, and User Acceptance testing. 6. Once the deployment process is properly documented and the configuration and development are confirmed to pass unit and functional tests, create a new FULL sandbox (complete copy of production, with data). 7. Follow the process from step 5 to deploy from Source Control to a Test sandbox, and perform Unit, Functional, and User Acceptance testing. 8. Follow the process from step 5 to deploy from Source Control to Production, and perform Unit, Functional, and User Acceptance testing. Steps 2 and 3 may be repeated as many times as necessary to ensure that the deployment process is fully documented and that all tests are passed. If additional development is required to pass any tests or to support the deployment process, a new development sandbox can be created and the configuration and code from the Development sandbox may be deployed, at which point the new sandbox becomes a development track like the existing sandboxes. Steps 4-7 may be repeated as many times as necessary to ensure a clean and error-free deployment process Cloud Inc. All Rights Reserved

6 THIRD PARTY SYSTEMS The Salesforce Software Development Lifecycle (SDLC), as enforced by the Force.com Platform, is unique in that it not only encourages, but also mandates testing using an exact replica of the production system. As a result, there are fewer differences between Development, Test, and Production, resulting in more reliable tests and fewer surprises during and following deployment. When deploying and testing Salesforce changes that impact external or third-party systems, there are a number of factors that must be taken into account: CONFIGURATION CHANGES IN THIRD-PARTY SYSTEMS Whether testing occurs with a configuration sandbox (configuration only, no data) or a Full Sandbox (with a copy of the Production data), it is important to configure the third-party systems to connect to the sandbox and not to the production system. This means that the third-party development and test sandboxes must have: The ability to change the SOAP endpoint (if they connect directly to Salesforce) used to connect to Salesforce. Production systems use login.salesforce.com as the authentication endpoint, while all sandboxes use test.salesforce.com. The ability to function with test data (for configuration sandboxes) or the ability to function properly with production data (including real customer data) without accidentally sending s or otherwise taking actions that should not occur in a test environment. The ability to change the authentication credentials to those used by the test sandbox. CONFIGURATION CHANGES IN MIDDLEWARE Similar to the changes required for third-party systems, any integration or middleware tools must be modified to point to both the Salesforce sandbox and the third-party software sandbox. When deploying changes to middleware, it is important to have a deployment process that easily accommodates: Replicating existing integration orchestrations Changing the endpoints and credentials to point to Dev and Test systems Disabling side-effects (such as s) that should not be sent by test orchestrations Testing and debugging Replacing the running orchestration with the changed version, and updating endpoints as appropriate Most middleware tools and third-party systems are not as tightly bound as Salesforce, and so are easier to configure to support complex testing and deployment environments, but they are also usually more complex. CONFIGURATION CHANGES IN SALESFORCE Because Salesforce sandboxes are exact replicas of production Salesforce environments, with or without production data, a number of steps must be taken to ensure that tests are safe and accurate: Test data in Full Sandboxes may need to be masked to hide personally identifiable information. This may be performed manually, or with tools like Informatica Data Mask. Test data may need to be created in configuration-only sandboxes (only Full sandboxes come with a copy of the Production data). Third-party credentials and endpoints may need to be changed. This implies that credentials and endpoints should be stored in Salesforce Custom Settings as much as possible rather than hard-coded. Configuration data that is stored in Salesforce objects, such as Rules Engine configuration tables, may need to be replicated from Production to a development sandbox in order for even limited testing to occur. Outbound messaging endpoints may need to be changed to reference the correct third-party test systems or middleware Cloud Inc. All Rights Reserved

7 CONFIGURATION MANAGEMENT Most Salesforce implementations use a combination of static settings (hard-coded or stored in Custom Settings) and lookup tables (e.g. reseller lookup tables, product lists) as configuration for business logic. These often include: Mapping tables to perform complex conversions between input values and values stored in Salesforce Product and Price book tables Employee tables Production and Testing endpoints and credentials (usually stored in Custom Settings) And more Although in many cases (as with Product tables) these tables can and should be edited directly in production, there are circumstances when business logic changes frequently enough to require a complex data model stored in Custom Objects rather than hard-coded or stored in Customer Settings. Changes to these tables should be made first in a Full Sandbox and subjected to functional and unit testing before being migrated to Production. The recommended architecture permits records to be edited in a sandbox, and then migrated to production by migrating records and record hierarchies using an ETL tool. A configuration-management environment In this diagram, a Configuration sandbox is periodically refreshed with configuration and data from Production (step 1), and configuration changes are synchronized using Informatica Cloud. Once the configuration changes are finalized, the Training sandbox and Support sandbox are synchronized to ensure that the live rules are used for employee training and support. This model can be extended in the same way as the SDLC model to support dev/deploy/ test/train configurations as well Cloud Inc. All Rights Reserved

8 EXTERNAL ID GENERATION To support this deployment model, configuration tables must all contain an External ID designed to be unique within the Salesforce ecosystem. This allows configuration from one Salesforce org (i.e. a Sandbox) to be migrated to another Salesforce org (i.e. Production) safely without the risk of accidental duplication, and ensures that changes made to a record are copied over to the same record in the other org. This does not eliminate the need to ensure that changes being migrated from multiple Sandboxes to Production (or bi-directionally between a Sandbox and Production) are timed to avoid inconsistencies. For example: Changes should never be made first in Production and then synchronized to a Sandbox unless care is taken to ensure that the Sandbox is already identical to the Production org. Globally unique external IDs are created using a Trigger on each of the configuration objects: 1. The External ID field will not be a required field. 2. A trigger on each object will be used to populate this field after insert with a GUID composed of the organization ID and the record ID (Organization. ID + : + record.id). Using both the Organization ID and the Record ID ensures that records created in two orgs will never have the same ID (because they will have different Organization ID components) and that records created in the same org will never have the same ID (because they will have different record ID components). For consistency, it is recommended that External IDs created for this purpose be named consistently. Whether you re looking for a simple or complex development or a configuration with third-parties or within Salesforce, be sure to follow the appropriate strategy. To learn more about Salesforce deployment strategy, including salesforce.com s documented best practices and recommended software development cycle, visit Cloud online at or Cloud Inc. All Rights Reserved