Skip to main content

(DevOps) What is Salesforce DevOps Center? Why do we need it?

 

(DevOps) What is Salesforce DevOps Center? Why do we need it?




Salesforce is planning to release a new Salesforce DevOps Center product which is a DevOps release management tool and will replace change sets in the near future. This release management tool bring DevOps best practices to deliver better visibility as well as traceability, to bring collaboration between teams to identify errors early so that releases can go smoothly.

So, what is Salesforce DevOps Center really? 


Salesforce DevOps Center is a release management tool built on Salesforce DX and utilise source member sObject. All changes will be tracked automatically and each change will be labelled by operation such as 'add', 'ignore', 'update' or 'remove'. As a result, you do not need to create package.xml and retrieve changes as Salesforce DevOps Center will do that for you. 

Salesforce DevOps Center lets you choose whether to manage your releases using its point-to-click interface, or directly from the source control system or a combination of both. Under the hood, Salesforce DevOps Center is built using Source Member sObject Tooling API along with Salesforce DX. and this allows to manage source control branches so developers and build professionals could focus on development tasks.

Since all changes are captured in a source control system, you have a single source of truth for configuration and code which improves collaboration across all functions: admins, developers, release managers, QA and other business stakeholders. 


                                Source: developer.salesforce.com/blogs


Key features of Salesforce DevOps Center:

1. Allows to organise your work - Track and deploy the changes with Work Items, a new object designed for DevOps Center and open to Salesforce Flows and other operations.

2. Track changes automatically - As advised above, Salesforce DevOps Center track changes automatically as you make them in development environments. DevOps Center shows a list of changed metadata components and allows you to select the ones you want to migrate. No more sticky notes, change sets, merge sandboxes or cumbersome interfaces are required to select changes.

3. Integrate seamlessly with GitHub for source control - Even if you have never used a source control before, DevOps Center makes it simple to adopt to a source control such as GitHub. All you need to do is connect to a GitHub instance/project from DevOps Center and it will make this integration easy.

4. Deploy changes with clicks - This is by far the most important and much needed feature of DevOps Center. It provides you to visualize your deployment pipeline, then simply click to deploy changes from one stage to the next. 

How many Metadata components are supported in DevOps Center?

For any release management tool, the first question asked by a release manager would be what types of metadata would be supported by that tool. Most of the time release management tools support all types of metadata but there are also certain limitations. 

There are around 470 metadata components supported by Salesforce. If you are an ISV Partner, it becomes important for you to support these metadata types in your app on the AppExchange package. The list of all metadata components supported by Salesforce are as shown in the link below:


Although there are lot of metadata components listed above, the release manager would need to check the org regularly to ensure that the components used in the release do not have any access level issues or disabled features to ensure that no error messages are getting displayed while retrieving metadata components inside the DevOps Center.

Why do we need it?

DevOps Center is designed to work for "hybrid" or "fusion" teams where teams are spread across the globe and made up of low-code developers to pro-code continuum developers. This means that you can do work inside or outside of the DevOps Center UI application so that things stay in sync. 

If your team users CLI or VS Code for committing changes to the source control, creating, reviewing and merging changes through pull requests are possible to do from outside of DevOps Center. DevOps Center will pick these actions and reflect them appropriately in the UI. It provides other teams to visualize the changes that were committed, access and review the pull requests and deploy the changes from inside the DevOps Center UI.


Source: developers.salesforce.com


Let's define the different elements involved in Salesforce DevOps Center and the relationships between them:

1. Releases - Any set of changes grouped together into a single package is a release. A release is split into one or more user stories.

2. User Stories - These user stories are created and defined during analysis phase with the end users. A user story is related to one or more Work Items. 

3. Work Items - Work Items contain the list of metadata components that are being changed, added or removed. You could create this list once similar to change sets for moving between orgs. The Work Item is pushed through pipeline stages from development orgs through to target org or customer's production environment.

4. Pipelines and Stages - The pipeline and stages are sequence of orgs (stages) where the Work Item is promoted (push) from development orgs to production. You could define separate pipelines for each type of release ex. "hot fix", "major", "minor", etc.

5. Bundled Stages - More than one stage in the pipeline can be marked as "bundled" stage. All the work items are promoted at the same time to the next stage.

6. Source Control - DevOps are incomplete with a source control. Under the hood, DevOps Center manages all the GitHub branches including moving metadata between branches and to target orgs. 

Current Limitations of Salesforce DevOps Center:


With any new product or tool, they are bound to have some limitations. Similarly, there are a few limitations with Salesforce DevOps Center as shown below:

1. No Support to ALM Solutions: Salesforce DevOps Center is not yet a complete release management tool and does not support ALM solutions such as JIRA, Azure, TFS, Version One, etc.

2. Source Control Limitation  The current beta version of Salesforce DevOps Center only supports GitHub as the source control by default. Other source control systems may not be supported.

3. No Rollback or backup feature: The current beta version of Salesforce DevOps Center does not provide support to rollback feature and backup feature after promoting a change in target org.

4. No support to unlocked packages: Salesforce DevOps Center does not provide support to unlocked packages and scratch orgs.

5. No integration with Automated testing tools: Currently there is no integration between automation testing tools such as Selenium, etc.

6. No code scanning feature:  Nowadays there are may code review tools such as 'Apex PMD' and the current beta version of Salesforce DevOps Center does not have integration with these tools. 

7. Branching issues - There is no ability to see if a metadata item is in a different work item in the release could be moved to a different release to another pipeline. This makes assessing the risk of promoting work items challenging. For ex, if a bug is fixed on a metadata item , the original version of this metadata item could still be promoted in the current release. 

How to overcome the above limitations in DevOps Center?

The Salesforce DevOps Center app is built on Heroku and is installed as a Managed Package. This means that it can be enhanced through an extension Managed Package.

Launched at Trailblazer DX'22, DevOps Center with Elements is the first partner extension package which overcomes most limitations discussed above which will hinder large scale adoption. This package is installed as additional Managed Package for Elements customers.

The extension package provides the following functionality in addition to Elements functionality:

  • Create Work Items in DevOps Center linked to a user story from Elements or in JIRA
  • Synchronise JIRA user stories, Element user stories and DevOps Work Items.
  • Aggregated view of metadata across Work Items for conflict resolution and release management.
Source: elements.cloud


As shown above, the elements panel synchronises the Elements user story with JIRA user stories and DevOps Center Work Items to promote to target org.

Here is the view of the flow between the Elements, Jira and DevOps connect and work together:

Source: elements.cloud


So, what is coming next?


The DevOps Center Beta is available to all orgs and can be downloaded from AppExchange packages. Start preparing by ensuring that you understand all the 3 principles of DevOps Center. Think through your business analysis and development processes as some organisations may require extensive changes to their existing processes.

Elements.cloud has developed a DevOps Center Implementation Guide which includes step-by-step instructions and implementation advice considerations when migrating from change sets and more. Register here to get a copy.

There is also an active Trailblazer Community on DevOps to get help and guidance -sfdc.co/devops-tb 

A demo is also available on DevOps Center with Elements here.














Comments

Popular posts from this blog

How do Sales Engagement Platforms drive Organisation’s revenue?

How do Sales Engagement Platforms drive Organisation’s revenue? Increasingly Sales Engagement platforms are used by organizations to enrich their sales teams with relevant information to improve their performance and increase sales productivity. These software tools help sales teams improve productivity by automating, optimising and analyzing their sales teams outreach and communication efforts. They typically provide a suite of features designed to help sales reps increase their productivity, improve their communication with prospects and customers leading to close more deals. Some common features of sales engagement platforms include: Email automation — Sales engagement platforms allow users to create and send personalized email messages to prospects and customers at scale. This helps sales reps to save time and increase their email response rates. Call automation — Some sales engagement platforms such as Gong, Chorus.io offer the ability to automate outbound phone calls, allowing sa

(DevOps) How to select a relevant Application Lifecycle Management (ALM) Salesforce model for your organisation?

  How to select a relevant Application Lifecycle Management Salesforce Model for your organisation ? Salesforce provides many different development tools and process to help meet customer requirements and needs. As many companies use Salesforce and Application Lifecycle management (ALM) processes, Salesforce has introduced three different models to manage ALM process within the organisation as shown below: Change set development Org development Package development From the surface all the above three development models follow the same ALM process. However, the models differ in the way they allow changes to your org and how you manage these changes. Controlling change is a huge deal in software development, and you could choose the development model that best suits your organisation needs and requirements. Firstly, let us understand what is the meaning of ALM for an organisation. Application Lifecycle Management is an integrated system of people, tools and processes that supervise a sof

(Ops) Why are organisations adopting PRM in Salesforce?

  Why are organisations adopting PRM in Salesforce? In this article, we focus on what is Partner Relationship Management and why organisations are increasingly adopting PRM solutions. We also discuss advantages and disadvantages of using Salesforce PRM to collaborate with partners. What is Partner Relationship Management (PRM)? The Partner Relationship Management solutions developed in the last 10-15 years is a type of software used by companies to facilitate execution of Channel Sales .  Channel Sales is a simple sales strategy used by companies to leverage the help of third-party vendors to sell your products and services. Channel sales strategies are usually deployed as part of your business growth effort. Channel Sales can help business grow in three key ways: To reach new customers who don't buy directly from the vendor, preferring instead to buy from resellers or ISV's (Independent software vendors). To sell products through third-party market places and managed service p