Choosing a Deployment Strategy for Development Systems

AgileApps Cloud platform package deployment is based on the publisher/subscriber model, where subscribers are expected to have customized key aspects of the package. In the publishing process, those aspects of the installed application are left alone. Package deployment is already optimized for the publisher/subscriber model, so if that's what you're doing you're in pretty good shape. You may want to double-check the behavior of things you'll be publishing, but there shouldn't be much you need to do.

Things get a little more interesting if you're deploying packages in a development scenario, where you have one or more development systems, a test system, and a production system. In that model, the application built in the development environment needs to be fully and completely replicated in the test environment. When it is ready for distribution, it must then be fully replicated in the production environment(s).

In that situation, there are several things you'll need to do.

Partition the Application

If you have multiple developers, the first step is to partition the application appropriately:

1. Make sure that only one person makes edits to any given aspect of an object.
   If multiple people add validations, for example, that can work. But only one person should make edits to existing validations, otherwise someone's work will get overwritten.

2. Each person who owns objects should package them and share the package with other developers.
   That step ensures that each of the development systems has the same object definitions.

3. Ideally, that person will be responsible for all additions to an object, as well.
   If several developers add validations, for example, an integration step is required to get all of the validations on the test system. (Each developer can publish to the test system--but then individual developers don't have the same set. Or they can all publish to each other--but that requires coordination. It's easier to make one person responsible for all of the validations, and all of the forms, field definitions, and other aspects of any given object.)

4. Similarly, make one person responsible for each of the other application artifacts like Roles and Tab Preferences.

Choose Your Deployment Model

The next step is choose your deployment model (sandbox deployment or publish/install):

• If you have created development sandboxes, it's natural to use Sandbox Deployment.

• The advantage of that process is that sandbox pathways are clearly defined.
• The disadvantage is that the owner of the target sandbox has no say in the matter--the deployment comes at them when the packager says, whether or not the target system is ready.
• Is also important to note that the deployment process still follows the publisher/subscriber model, and that the same rules apply. So choosing sandbox deployment doesn't automatically replace everything on the target system.

• As a result, it is common even in the development scenario to use the normal publication process, where the packager "publishes" a package to make it available, after which the target systems install the package. The advantages of that process are:

• The installer can choose when to install the package.
• The installer can see what's in the package

But:

• The installer needs to be sure to choose the "override roles" option during the installation, to be sure that any changes that were made to existing roles are reflected on the target system.

Create and Deploy the Package

1. When creating the package, include the Users Object if any new fields or business rules have been added that the application depends on.
2. After it is created, use your preferred deployment strategy to update target installations.

Perform Necessary Manual Replications

Finally, you need to make sure that each system targeted by the deployment process is an accurate reflection of the packaged application.

To do that:

1. Publish the package in "overwrite" mode, so that deletes (for most package items) are replicated in the target environment.

   Learn more: Packaging option

2. The package installer should choose the override option for roles, in case any role-definitions have changed. (Most developer-environments will also choose overwrite, unless they have been working on roles, in which case they will choose to merge role definitions.)

   Learn more: Subscriber choice

3. On all target systems, manually delete any of these elements that are no longer needed:

   • Applications

     This step is required only if an application-definition was added as a result of a Package Dependency, and that application is no longer needed.

     When you delete the application, components shared by other applications remain. Only components that are unique to the application are deleted.

   • Classes
   • Global Picklists
   • Object Web Forms
   • Processes
   • Roles

4. On all target systems, manually replicate any changes made to these items, and manually delete any that were removed:

   • Business Hours Calenders
   • Case Object Quick Text
   • Customer Satisfaction Surveys
   • Object Email Templates
   • Site definitions
   • SLAs
   • Team definitions
   • Template Variables (global variables available to all templates)

5. On all target systems, manually replicate any changes made to these system components (but only if they need to be replicated in the target environment):

   • Access Profiles
   • Business Calendars
   • SLAs

6. Make any required customizations to the target system:
   • Web Service end-point URLS
     If the target system will continue connecting with the service it was using before, nothing needs to be done. (The URLs are expected to be different in development, test, or production environments, so they are not modified, even when the Web Service is updated.) But if service URL for Web Service end point needs to change on the target system, then manually make that modification.