DevOps Center Checkup 153 Days Later
When I first became aware of DevOps center 9 months ago, I was ecstatic to see what it could do. Automatically track changes? Amazing. Native integration with GitHub and changing to a source-tracking paradigm? Beautiful. It was clear to me that this feature was widely discussed as well. So many articles discussed setting up DevOps center, and discussed it’s potential. But, one thing was eerily missing. No one talked about using the tool.
The Potential Of DevOps Center
The potential of the tool was certainly hyped up. After being released as a beta in June 2022, there were no shortage of tutorials on how to configure and setup DevOps center. There were many reasons to be excited as well. Some of the out-of-the-box features included:
- Git source tracking
- Tracking work items in Salesforce
- Pipelines to push items through environments
This tool was meant to replace change sets, an antiquated and cumbersome tool that allows Salesforce admins and developers to push changes between environments.
Setting Up DevOps Center
Setting up DevOps Center is easy to configure for an org. After about an hour of configuring, pushing changes through DevOps center is ready. You can see more about how to configure here:
Day To Day Usage
Initially, using the tool is intuitive and easy. A sample workflow to push changes is as follows:
1. Create Work Item inside DevOps center
2. Select the sandbox (environment) changes were made in
3. Add the changes to the Work Item
4. Commit the changes to the Work Item
5. Promote the Work Item through Work Item Bundles to production
And when everything works within DevOps center, it’s fast to promote changes. It’s easy to identify what changes were made, and pushing them takes less time than through change sets. But when you work with DevOps center day-to-day, things stop working ‘as intended’.
Initial Shortcomings
There are some initial things that, even after seeing the tool for the first time, should have been included. These include:
- Jira Integration
- Other git platforms like Bitbucket or GitLab.
And while there is a place to give feedback here, it’s clear that there are more problems than outlined above.
For starters, there are a few things that could be implemented that can easily improve productivity. Things like saving your filters when viewing all work items can vastly improve performance and speed to push changes. Additionally, adding a way to view test class results would speed up changes if tests failed. While I raised this issue back in November, there still is no easy way of seeing test class results. My current process to see test class failures is:
1. Recreate the work items as a change set
2. Validate the change set in production
This is a pretty telling workaround to resolve such a vital and necessary feature in pushing changes.
But as I continued to use the tool, it was clear that this was not the only problem I was going to run into.
Problems with Source Tracking
After using the tool for a few months, some serious issues started rearing their head. This included:
- Refreshing a sandbox broke source tracking
- Environments never in sync in DevOps Center
- Committing directly to work item branches through git never worked
These aren’t minor problems. They are fundamental to the health and stability of the tool. In practice, this means that I spend more time fighting against the tool than using it. Not being able to commit through git means collaboration between developers is thrown out the window. Additionally, because the sandbox refresh breaks source tracking, this means that:
- Changes made to an environment stay indefinitely
- Manually adding changes to the work item
Furthermore, to fix this issue, it is recommended to break the connection with the sandbox, and reconnect as a new environment. A graveyard of environments is created if a sandbox is ever refreshed.
Not committing code to a work item branch through git is not a workaround. When directly committing work through DevOps center, a sample workflow to keep code source clean is:
1. Push code to Sandbox
2. Create Work Item In DevOps Center
3. Push changes through pipeline
4. Run `git reset — hard origin/main` to fix code locally
Problems Collaborating
DevOps center must be installed in production. This makes sense intuitively. But when working with a team, not every team member has access to production. And team members who do not have access to production cannot commit their changes. This would be fine, if committing through work branches in git worked.
Conclusion
The hype for a new deployment process is the Salesforce community agreeing that change sets are an antiquated process. But DevOps center is just a fresh coat of paint on an old process. Seeing that the feedback has not only slowed down, but responses to feedback have also disappeared, foreshadows a bleak future for this tool.
If you are interested in how 1Sync can support your Salesforce needs, get in touch.
This article was originally posted here
