MyPage is a personalized page based on your interests.The page is customized to help you to find content that matters you the most.


I'm not curious

The Salesforce Release Train: A Practical Approach to Release Management

Published on 26 September 17
929
0
1

Release management, as the name suggests, is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases (Humble & Farley, 2011).

It is a pretty big topic in itself and can only be perfected over time by trying different iterations with the development teams and matching business needs or feature releases. We will try to cover the industry practices of metadata management, CI building, and sandbox management for managing an organization’s release train.

But what is a release train?

A release train is an incremental and predictable feature delivery technique. It requires the developer to set up a formal process to take any changes made in the development environment and deploy them to production.

The Salesforce Release Train: A Practical Approach to Release Management - Image 1

A release train can broadly be divided into three segments:

  • Metadata management
  • Continuous integration build
  • Sandbox management

Metadata Management

Metadata is data that provides information about other data. Salesforce provides a rich and powerful metadata model via its Metadata API. Your application metadata describes and encompasses a set of methods that provide programmatic access to the source code and configuration of your organization.

The Metadata API is the best way to manage the customizations in Salesforce. It supports create,read,update,and delete methods. You can use Change Sets, the Force.com IDE, and the Ant Migration Tool to migrate metadata from one org to another, since they all provide migrations via the API.

Each tool has its own advantages, and there are several things to consider when picking one:

Table 1: Tool Comparison for Metadata Migration

Change SetsForce.com IDEAnt Migration Tool
Change Sets are the way to deploy components via the standard Salesforce UI.Force.com IDE (Eclipse) is primarily intended for Apex development, but can be used for deployment purposes.Ant Migration is a powerful command line tool, dedicated for migrating changes/metadata between environments.
Usually used for a small number of component migration.Developers usually use the IDE for migrating changes to the testing or staging environment.Ant Migration is used for Large payload migration and needs advanced knowledge of the Salesforce Metadata API.
Connection between the orgs has to be manually established, so it isn’t suitable for automated deployments.It can be used to deploy to any org, but needs some manual steps, which are error prone.Automatic deployments can be scheduled very easily.
Intended for use by administrators.Geared towards salesforce developers, since developing the code is its primary use.Geared towards DevOps engineers.
Adding dependencies is very easy and user friendly.Adding dependencies is somewhat easy, as it provides a point and click UI.Deployment usually fails due to missing dependencies.
Doesn’t allow destructive changes.Does allow destructive change sets but the process is quite tedious.Allows destructive change sets.

The Metadata API is great at serving its purpose when developing and migrating changes on the Force.com platform. But there is a slight catch - not all of the Salesforce metadata is supported by the Metadata API. The official documentation provides a list of unsupported components.

If your organization is making changes that are not supported by the Metadata API, you have to make sure to replicate those changes manually in the destination org. The best way track these changes is a spreadsheet. If you have to resort to this approach, it’s always advisable for a single person to make these changes and track them.

This would be a good general list of columns that one could use for tracking these changes in a spreadsheet:

  • Name of component
  • Type of component
  • Change owner
  • Description of functionality
  • Capability mapping
  • Dependency with other components
  • Reviewed/reviewer name
  • URL
  • Org name/ID
  • Other comments

Version Control and Continuous Integration

Migrating changes to production should be a smooth process, since it’s just a repeat of applying changes in the testing and staging environment. Still, there is always a chance of things going south, and then you need a fallback plan. It’s very important to keep backup of your org’s metadata, and that’s what version control and the CI build are for.

Version control is an absolute must for any organization. It allows developers to work in a collaborative, efficient, and safe way. Managing multi-developer, multi-sandbox code development and migration is a challenge in Salesforce. Salesforce also has its own schedule for releases and maintenance. These updates deliver new features, but they could introduce a change in the Metadata API which may break your CI build. So, apart from situations where developers are overwriting each other’s changes, version control helps you in building a rollback strategy. Having a rollback strategy is a must when your application runs on Force.com.

The following flow diagram depicts a practical structure for Version Control and CI. We’ll try to give you a quick description on what the diagram represents.

  1. A developer would check in their change in the version control system.
  2. The CI Server/Jenkins would deploy the latest build to the CI sandbox and run test classes.
  3. If the deployment in step 2 is successful, then changes are merged into the QA branch.
  4. CI would then deploy the latest commit from the QA branch to the QA sandbox.
  5. If QA rejects the changes due to test failures, steps 1 through 3 should be performed again until QA clears the changes.
  6. After the changes pass testing in QA, the changes are merged into the Master branch.
  7. Latest changes from the Master branch are deployed to the Master sandbox.

The Salesforce Release Train: A Practical Approach to Release Management - Image 2

One can choose to add more branches depending on the organization’s needs. But the above structure just works fine for the medium to enterprise level development structures.

Sandbox Management

To get most out of the DevOps process of your organization, it’s very important to set up the sandbox structure. Before we dive much deeper into it, let’s discuss the different types of sandboxes Salesforce offers us.

A sandbox is an almost exact copy of one’s production metadata. Sandboxes are typically used for development, testing, staging, and training purposes. There are four types of sandboxes, and one should give a due consideration while choosing a sandbox. Full Copy sandboxes could cost a lot of money!

Below is the table for the limits enforced by Salesforce for different sandboxes.

Table 2: Limit Comparison

DeveloperDeveloper ProPartial CopyFull Copy
Production DataNoNoYesYes
Data Storage200 MB1 GB5GB (10K records per object)Complete Data
Refresh Period1 Day1 Day5 Day29 Day

We can see that price isn’t the only difference between sandboxes.

The developer sandbox has a one-day refresh period, which makes it suitable for development, but can only accommodate 200 MB of data, and no production data. As a polar opposite, full copy sandboxes have an exact copy of the production data; even the record IDs are the same. That could make it great for testing and staging, but the refresh period of 29 days makes it difficult to get the latest production metadata and data in the full copy sandbox.

The table below acts as a rule of thumb for selecting sandboxes:

Table 3: Use Cases for Sandbox Selection

DeveloperDeveloper ProPartial CopyFull Copy
DevelopmentYesYesNoNo
QAYesYesYesNo
Integration TestNoNoYesYes
Batch Data TestNoNoYesYes
TrainingNoNoYesYes
UATNoNoYesYes
Load TestNoNoNoYes
StagingNoNoNoYes
User TrainingNoNoNoYes

Below is the typical org structure which is adopted for medium-sized projects. For enterprise level clients, the org structure becomes more complex but broadly follows the model below.

The Salesforce Release Train: A Practical Approach to Release Management - Image 3

Development work is usually done in the developer sandbox (red) and the changes are moved to the integration sandbox (green) which is usually a developer pro or a partial copy sandbox. Then the changes from multiple integration sandboxes are moved up to the rollup sandbox (yellow) which should be a partial copy sandbox.

If your organization has any integrations with the third-party system that needs integration testing and load testing to be performed, one needs to have a stable set of data that doesn’t change from release to release. So, it’s better to have a full copy or partial copy sandbox for it.

These changes are then moved to the integration testing sandbox, where tests are performed. Then the changes are moved to the staging sandbox, which should be a full copy sandbox. All the test classes are run before deployment. A deployment validation should be performed to make sure that deployment happens without any issues.

This process helps us make sure that the changes go through multiple rounds of testing and pairs of eyes. It comes with a heavy downside of requiring a lot of time to develop, test, and deploy changes.

Very often, there is an urgent need to perform bug fixes or patches. To handle these quickly, one should keep a developer sandbox, which would push small patches directly to the rollup sandbox.

As mentioned previously, a sandbox is an almost exact replica of production metadata, but not completely. There is an official list of components/features which are disabled in a sandbox.

Another thing to consider while refreshing a sandbox is that it only copies the production metadata and data. There is no way to copy the metadata from one sandbox to another, or even to create an empty sandbox without any metadata configurations (like free developer orgs). This sometimes becomes a challenge in real life situations. Salesforce has plans to address this issue, and this feature may soon become generally available.

Additionally, if you have some sensitive data in production, which you feel that your development or testing team should not have access to, you can create sandbox templates for fully and partially copied sandboxes.

What to Consider When You Deploy

We have covered the industry practices of application lifecycle management in the Salesforce ecosystem. Metadata and sandbox management play a very important role in creating the deployment packages and payloads. For large and complex Salesforce applications, version control helps in making sure that the metadata changes are tracked while also helping in the creation of a rollback strategy.

Sandbox management is critical for large or complex projects. But the Sandboxes are costly in the Salesforce ecosystem, both in terms of financial resources and time. Formulating a strategy for sandbox management is always critical for the release management process.

We’ll leave you with some extra points that would be good to keep in mind during your next deployment:

  1. Only 10,000 files, or a 39 MB ZIP file, can be deployed in one go. Naturally, if the payload is too big, you have to divide the package in multiple parts and then do the deployment.
  2. If the deployment is failing due to a request timeout error, try removing objects, custom fields, and profiles from the package. These components take longer to deploy.
  3. If a field type is changed, or there have been changes in the role hierarchy, then there could be long delays due to data recalculation, requiring some time to complete.
  4. Salesforce locks any component that is being currently used by a user in the system. If we try to deploy while that is the case, deployment will fail.
This article is written by Ajinkya Deshmukh and originally appeared at Toptal
29
Release management, as the name suggests, is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases (Humble & Farley, 2011).

It is a pretty big topic in itself and can only be perfected over time by trying different iterations with the development teams and matching business needs or feature releases. We will try to cover the industry practices of metadata management, CI building, and sandbox management for managing an organization’s release train.

But what is a release train?

A release train is an incremental and predictable feature delivery technique. It requires the developer to set up a formal process to take any changes made in the development environment and deploy them to production.

The Salesforce Release Train: A Practical Approach to Release Management - Image 1

A release train can broadly be divided into three segments:

  • Metadata management
  • Continuous integration build
  • Sandbox management
Metadata Management

Metadata is data that provides information about other data. Salesforce provides a rich and powerful metadata model via its Metadata API. Your application metadata describes and encompasses a set of methods that provide programmatic access to the source code and configuration of your organization.

The Metadata API is the best way to manage the customizations in Salesforce. It createreadupdatedelete. You can use Change Sets, the Force.com IDE, and the Ant Migration Tool to migrate metadata from one org to since they all provide migrations via the API.

Each tool has its own advantages, and there are several things to consider when picking one:

Table 1: Tool Comparison for Metadata Migration

Change Sets

Force.com IDE

Ant Migration Tool

Change Sets are the way to deploy components via the standard Salesforce UI.

Force.com IDE (Eclipse) is primarily intended for Apex but can be used for deployment purposes.

Ant Migration is a powerful command line tool, dedicated for migrating changes/metadata between environments.

Usually used for a small number of component migration.

Developers usually use the IDE for migrating changes to the testing or staging environment.

Ant Migration is used for Large payload migration and needs advanced knowledge of the Salesforce Metadata API.

between the has to be manually established, so it isn’t suitable for automated deployments.

It can be used to deploy to any but needs some manual steps, which are .

Automatic deployments can be scheduled very easily.

Intended for use by administrators.

Geared towards salesforce developers, since developing the code is its primary use.

Geared towards DevOps engineers.

Adding dependencies is very easy and .

Adding dependencies is somewhat easy, as it provides a point and UI.

Deployment usually fails due to missing dependencies.

Doesn’t allow destructive changes.

Does allow destructive but the process is quite tedious.

Allows destructive .

The Metadata API is great at serving its purpose when developing and migrating changes on the Force.com platform. But there is a slight catch - not all of the Salesforce metadata is supported by the Metadata API. The official documentation provides a list of unsupported components.

If your organization is making changes that are not supported by the Metadata API, you have to make sure to replicate those changes manually in the destination org. The best way track these changes is a spreadsheet. If you have to resort to this approach, it’s always advisable for a single person to make these changes and track them.

This would be a good general list of columns that one could use for tracking these changes in a spreadsheet:

  • Name of component
  • Type of component
  • Change owner
  • Description of functionality
  • Capability mapping
  • Dependency with other components
  • Reviewed/reviewer name
  • URL
  • Org name/ID
  • Other comments
Version Control and Continuous Integration

Migrating changes to production should be a smooth since it’s just a repeat of applying changes in the testing and staging environment. Still, there is always a chance of things going south, and then you need a fallback plan. It’s very important to keep of your org’s metadata, and that’s what version control and the CI build are for.

Version control is an absolute must for any organization. It allows developers to work in a collaborative, efficient, and safe way. Managing multi-developer, multi-sandbox code development and migration is a challenge in Salesforce. Salesforce also has its own schedule for releases and maintenance. These updates deliver new features, but they could introduce a change in the Metadata API which may break your CI build. So, apart from situations where developers are overwriting each other’s changes, version control helps you in building a rollback strategy. Having a rollback strategy is a must when your application runs on Force.com.

The following flow diagram depicts a practical structure for Version Control and CI. We’ll try to give you a quick description what the diagram represents.

  1. A developer would check in their change in the version control system.
  2. The CI Server/Jenkins would deploy the latest build to the CI sandbox and run test classes.
  3. If the deployment in step 2 is successful, then changes are merged into the QA branch.
  4. would then deploy the latest commit from the QA branch to the QA sandbox.
  5. If QA rejects the changes due to test failures, steps 1 through 3 should be performed again until QA clears the changes.
  6. After the changes pass testing in QA, the changes are merged into the Master branch.
  7. Latest changes from the Master branch are deployed to the Master sandbox.
The Salesforce Release Train: A Practical Approach to Release Management - Image 2

One can choose to add more branches depending on the organization’s needs. But the above structure just works fine for the medium to enterprise level development structures.

Sandbox Management

To get most out of the DevOps process of your organization, it’s very important to set up the sandbox structure. Before we dive much deeper into it, let’s discuss the different types of sandboxes Salesforce offers us.

A sandbox is an almost exact copy of one’s production metadata. Sandboxes are typically used for development, testing, staging, and training purposes. There are four types of sandboxes, and one should give a due consideration while choosing a sandbox. Full Copy sandboxes could cost a lot of money!

Below is the table for the limits enforced by Salesforce for different sandboxes.

Table 2: Limit Comparison

Pro

Partial Copy

Full Copy

Production Data

No

No

Yes

Yes

Data Storage

200 MB

1 GB

5GB (10K records per object)

Complete Data

Refresh Period

1 Day

1 Day

5 Day

29 Day

We can see that price isn’t the only difference between sandboxes.

The developer sandbox has a one-day refresh period, which makes it suitable for development, but can only accommodate 200 MB of data, and no production data. As a polar opposite, full copy sandboxes have an exact copy of the production data; even the record IDs are the same. That could make it great for testing and staging, but the refresh period of 29 days makes it difficult to get the latest production metadata and data in the full copy sandbox.

The table below acts as a rule of thumb for selecting sandboxes:

Table 3: Use Cases for Sandbox Selection

Pro

Partial Copy

Full Copy

Development

Yes

Yes

No

No

QA

Yes

Yes

Yes

No

Integration Test

No

No

Yes

Yes

Batch Data Test

No

No

Yes

Yes

Training

No

No

Yes

Yes

UAT

No

No

Yes

Yes

Load Test

No

No

No

Yes

Staging

No

No

No

Yes

User Training

No

No

No

Yes

Below is the typical structure which is for medium-sized projects. For enterprise level clients, the org structure becomes more complex but broadly follows the model below.

The Salesforce Release Train: A Practical Approach to Release Management - Image 3

Development work is usually done in the developer sandbox (red) and the changes are moved to the integration sandbox (green) which is usually a developer pro or a partial copy sandbox. Then the changes from multiple integration sandboxes are moved up to the sandbox (yellow) which should be a partial copy sandbox.

If your organization has any with the third-party system that needs integration testing and load testing to be performed, one needs to have a stable set of data that doesn’t change from release to release. So, it’s better to have a full copy or partial copy sandbox for it.

These changes are then moved to the integration testing sandbox, where tests are performed. Then the changes are moved to the staging sandbox, which should be a full copy sandbox. All the test classes are run before deployment. A deployment validation should be performed to make sure that deployment happens without any issues.

This process helps us make sure that the changes go through multiple rounds of testing and pairs of eyes. It comes with a heavy downside of requiring a lot of time to develop, test, and deploy changes.

Very often, there is an urgent need to perform bug fixes or patches. To handle these quickly, one should keep a developer sandbox, which would push small patches directly to the sandbox.

As mentioned previously, a sandbox is an almost exact replica of production metadata, but not completely. There is an official list of components/features which are disabled in a sandbox.

Another thing to consider while refreshing a sandbox is that it only copies the production metadata and data. There is no way to copy the metadata from one sandbox to or even to create an empty sandbox without any metadata configurations (like free developer ). This sometimes becomes a challenge in real life situations. Salesforce has plans to address this issue, and this feature may soon become generally available.

Additionally, if you have some sensitive data in production, which you feel that your development or testing team should not have access to, you can create sandbox templates for fully and partially copied sandboxes.

What to Consider When You Deploy

We have covered the industry practices of application lifecycle management in the Salesforce ecosystem. Metadata and sandbox management play a very important role in creating the deployment packages and payloads. For large and complex Salesforce applications, version control helps in making sure that the metadata changes are tracked while also helping in the creation of a rollback strategy.

Sandbox management is critical for large or complex projects. But the Sandboxes are costly in the Salesforce ecosystem, both in terms of financial resources and time. Formulating a strategy for sandbox management is always critical for the release management process.

We’ll leave you with some extra points that would be good to keep in mind during your next deployment:

  1. Only 10,000 files, or a 39 MB ZIP file, can be deployed in one go. Naturally, if the payload is too big, you have to divide the multiple parts and then do the deployment.
  2. If the deployment is failing due to request timeout, try removing objects, custom fields, and profiles from the package. These components take longer to deploy.
  3. If a field type is changed, or there have been changes in the role hierarchy, then there could be long delays due to data recalculation, requiring some time to complete.
  4. Salesforce locks any component that is being currently used by a user in the system. If we try to deploy while that is the case, deployment will fail.
This article is written by Ajinkya Deshmukh and originally appeared at Toptal

29

This blog is listed under Development & Implementations Community

Related Posts:
Post a Comment

Please notify me the replies via email.

Important:
  • We hope the conversations that take place on MyTechLogy.com will be constructive and thought-provoking.
  • To ensure the quality of the discussion, our moderators may review/edit the comments for clarity and relevance.
  • Comments that are promotional, mean-spirited, or off-topic may be deleted per the moderators' judgment.
You may also be interested in
Awards & Accolades for MyTechLogy
Winner of
REDHERRING
Top 100 Asia
Finalist at SiTF Awards 2014 under the category Best Social & Community Product
Finalist at HR Vendor of the Year 2015 Awards under the category Best Learning Management System
Finalist at HR Vendor of the Year 2015 Awards under the category Best Talent Management Software
Hidden Image Url

Back to Top