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.

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:

   • 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
   • Classes
   • Global Picklists
   • Object Email Templates
   • Object Web Forms
   • Site definitions
   • SLAs
   • Team definitions
   • (global) Template Variables

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 Services
     (A developer may use a local Web Service. The test system may use a remote server that has been set up to return a few records, while the production system may use an actual service that returns hundreds. After deployment, each target system will need to redo the customizations to the Web Service definition.)