Release management

Release management is a framework which controls the deployments from one org to another. It depends on many aspects of organization like business strategy, business objectives, governance, change management etc. It sounds overwhelming and chaotic if you are new to this. But, that's fine. This is how everyone must have felt when they have started learning  Release engineering !!

Before taking a leap into Release management, there are some important concepts which shouldn't be skipped.

Releases typically fall into three categories :

Patch / Hot fixes - Bug fixes and simple changes related to Reports, Dashboards and List views

Minor - Changes like creating a new workflow rule or trigger. Testing is required for the minor changes too

Major - Changes with significant impact to the business process also needs through testing. Major changes usually are delivered once in a quarter

Which of these three categories do you think is a safe change in production?

Customizations such as developing new dashboards, reports, email templates which don't affect the data can be made directly in the production. Hot fixes can be done directly in production as they don't affect the data.

Minor changes like Workflow rule, change in field type, validation rules, Page layout changes can create an infinite loop or sometimes cannot be undone or may confuse the users. That's the reason these kind of customizations are to be tested in a  different org and then to be deployed in production.

Major changes are usually done with the help of Apex. Apex code cannot be written in production org. Code can be developed in another org, tested and then deployed to production org.

Flow of Customizations to Production:

 👬Developing     →   Testing     →  Staging ( UAT )  →  Production 👬👬👬

             ⇡                         ⇡                        ⇡                             ⇡

  ( Developer org )       ( Sandbox )       ( Sandbox )         ( Production org )

Production org : Live users uses data

Developer org  : An org created with Developer edition where developers can code

Sandbox org     : Copy of metadata same as Production org

Sandbox types  : Developer Sandbox, Developer Pro, Partial copy & Full copy

                        

Every company has different projects and each of them are developed and tested in a separate org. After testing & UAT the changes are deployed in to production org.

Depending on the size of the company and according to their projects running in parallel, they can have one Full copy Sandbox and two Partial copy Sandbox or can have two Full copy Sandbox and a Partial copy Sandbox. There is no rule that every company will have the same set of Sandbox.

Change and Release management can be a very tedious task when there are many projects in development. No worries!! There are many tools available for automating the Release management process which will be discussed in detail in my upcoming posts.

Summary:

Managing deployments is generally considered as one of the most difficult aspects of Salesforce platform. That's the reason most of the companies follow a process and iterate. At every iteration, small changes are made instead of shaking the whole boat.

Release management in any company takes significant amount of time before the process gets matured !!