Release Management - II

Hi Rangers, 

Hope You enjoyed learning about Application life cycle management in my previous blog of Release Management. If you haven't visited it yet, do check it out before beginning this module. Today we'll be learning about Development models -

Development Models:

  •       Change Set development
  •       Org Development
  •       Package development

All these three development models are similar as they all follow the same ALM process, the only difference lies in the way they all manage changes in org. Different development model suits various situation.

Change set Development

It’s not necessary to find all the changes in the component in Metadata API so those changes need to be moved manually from one environment to another.

As a release manager, you would need to include dependent component in the release otherwise the deployment may lead to failure. Let me just example it with the help of example, suppose you want to migrate a custom field to another environment, and you noticed that the custom object belonging to that field doesn’t exist in the environment. Then in this case it would lead to failure. Thus, change set helps in identifying these dependencies.

ORG Development

With the growing size of the team, it’s difficult to manage with change set development process. Now team needs a better change management process to manage multiple workstreams. There are certain limitations like – deletion of fields not allowed, you can only add the fields.

In org development, Salesforce CLI is used to retrieve the changes from the development environment instead of using declarative tools to create a change set. Team members are suppose to integrate their work with VCS( Version Control Systems) , so that the changes done by them can be retrieved and tracked in the VCS.

The major difference between org development and change set development – sometimes team members may actually overwrite someone else’s changes by deploying a change set directly. By using org development- we tend to apply the new way of  committing changes to VCS, all the customizations, conflicts can be brought into our notice before the new change gets deployed or overwritten.

1. Firstly in build step, the customizations or changes from the team are integrated into the project in source control.

2. From the VCS, changes are deployed together to build environment for integration and testing.

(Note: These changes are tested together in the build environment on the similar ground of change set process and the result is a single artifact which is a consolidated set of changes.)

3. Salesforce CLI is used to retrieve the artifact from the build environment. And as the org development process goes on, the release artifact keeps moving from the VCS onwards to the next environment.

4.Though additional tools in the org development process are being used, the basic ALM steps, change set concept, and the environment for development and testing are the same.  Everyone working on the first release under the new development model has at least some familiar points of reference.

Hope you enjoyed learning.

Thank You !! Happy Trailblazing!!!!!


Popular posts from this blog

Release Management - I

Apex Specialist - Challenge 6

Creating Fields in bulk