My Hopes for Salesforce DX

I work in a large IT shop with a large development team outside of Salesforce. We build and support many applications supporting various business units and internal resource groups. We use a release management tool that consumes code from a TFS server, builds said code, and then deploys that app to various environments. As most of our applications live within the local network, this process is fairly streamlined. Managing Salesforce metadata within our repository and deploying to our sandbox and production environments custom tools has been a royal pain. My hope is for Salesforce DX to vastly improve the release process to align with the rest of the dev teams.

Scratch Orgs – With our growing Salesforce team of admins and developers, making changes within an org has been increasingly more challenging. With scratch orgs, we can collaborate better in conjunction with Git merging/pushing/pulling. Another big plus is having the ability to use test data for some of our more complicated apps. Full sandboxes are extremely expensive and partial sandboxes only work if you have minimal data per object.

Git – The ability to push, pull, and merge metadata will be so great. Currently our team works in their own sandbox to make changes. Whether those changes are declarative or code-based, most of the time we have to copy/paste or recreate in our integration sandbox. From that sandbox we Eclipse to pull all of the metadata to the hard drive and then check those files in to TFS; a very arduous and error prone process. Ideally, I would like to utilize the Git functionality on our TFS servers to replace our current process with TFS.

I was able to get an invitation for the Salesforce DX pilot. With the end of June and pilot ending soon, I wasn’t able to test out all the features besides the basic needs for our team. Extended project timelines at work have not allowed me the free time I wanted to test. Although, the little testing I was able to do reaffirmed my initial excitement of DX. I’ve been excited for DX ever since it was hinted at last year.

Last year when our team was looking for solutions, we could have gone with cloud-based solutions like Flosum or Autorabit, which are designed to solve release management problems. After trying out both options, they did meet our basic requirements but were very clunky feeling and lacked the streamlined release processes of our other development teams. Naturally, I was hesitant about our team adopting one of these products that have decent price tags on them.

When hints about an improved development and continuous integration tool came from the mighty Salesforce itself, I encouraged our team to wait until Dreamforce to see what all the fuss was about. Sure enough, the developer keynote and sessions gave way to a new opportunity. Suddenly the possibility of keeping our metadata within our systems and plugging in DX was very exciting.

The pilot was a great preview of what to expect. The CLI handled everything we needed for metadata integration, but I was more excited about the DX IDE. Most of our team are declarative admins so point and click features with an IDE are definitely preferred. However, many of the awesome features of DX remained within the CLI, and I would hope they integrate more commands in the future to allow teams to merge, pull, push, etc., without having to pull up a separate tool. It seems the Salesforce dev team primarily has other developers in mind, which is great for me, but I am glad that this will encompass declarative features as well.

Speaking of the IDE, I hope it becomes a decent developer tool for apex, visualforce, and lightning. I have never been thrilled with developing in Eclipse or the developer console, so I hope they improve that experience. Being able to navigate through code and debug that code is very important to me. Perhaps mimicking some of the features the Welkin Suite has been doing would be fantastic. The Welkin Suite is great because it allows you to debug your code without having to keep a connection with Salesforce servers. It also allows you to use a lot of tools Visual Studio has, so traversing code from function to function between classes is a breeze. I was born a Visual Studio coder so I am definitely biased.

With the beta coming out for Salesforce DX, I hope to see more changes. I know my use case is very narrow when it comes to DX and Git functionality but I’d like to hear from others who are in the same boat. What other features would you like to see emphasized with DX?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s