Dreamforce 2017 had more developer content than last year, with Salesforce DX being the main topic. Blue Canvas demoed their Salesforce DX integration and discussed simplifying Git flow and CI for Salesforce. Teams also discussed ways to get admins and less technical team members into source control, and a new flow for Salesforce development may need to be developed. SOX compliance and myTrailhead were also discussed, while there was less buzz about Einstein and Lightning.
With this article, learn about the key takeaways from Dreamforce 2017, including the excitement around Salesforce DX, the challenges of integrating source control and CI for Salesforce, and new ideas for simplifying the development flow.
Here are our 5 Key Takeaways:
1. Salesforce DX was the main topic of conversation at Dreamforce, with universal enthusiasm for its direction and benefits.
2. Integrating source control and CI for Salesforce can be challenging, but solutions like automatic commits to Git and a hosted service like Blue Canvas can simplify the process.
3. A new development flow for Salesforce may be needed, with ideas like having a Sandbox for each feature release.
4. Audit trails and SOX compliance are becoming more important for Salesforce development teams.
5. myTrailhead is an exciting new feature that focuses on customer training and could have a profound impact on customer success.
We had an amazing week at Dreamforce. There is a real energy that comes from that conference. This year there was more learning than ever. We wondered whether the addition of TrailheaDX as an annual staple would dilute the quality of developer content. But we were pleasantly surprised to feel that Dreamforce had more developer content than we remember last year.
Going into Dreamforce, we had a few major questions that we wanted answered. Alex dropped by Salesforce Ben’s blog to talk about the 3 Big Questions for Developers at Dreamforce . Some of our questions but of course more were raised by the end.
Because the best part about Dreamforce though is the discussion. We always get the most value out of the little hallway chats you have, the shared insights and ideas that come from hearing what everyone is working on. We loved talking to new and old friends like Provar Testing , Code Scan , Prodly , The Welkin Suite and Illuminated Cloud . Accordingly, we thought we’d quickly summarize some of our best conversations and themes from the week. We’ll post in more detail on some of these in the coming weeks.
Integrating Salesforce DX into a Workflow is Exciting but Challenging The main topic on everyone’s mind was Salesforce DX. There were over 10 sessions about it and it featured prominently in the Developer keynote . Salesforce DX literally came up in every conversation we had. There was universal enthusiasm for DX and the direction it is taking. Salesforce developers feel appreciated and heard in a way they haven’t felt in years.
Many teams were asking us how they could integrate DX into their workflow without being too disruptive. After all, scratch orgs require a new directory structure that makes it slightly challenging to work with existing sandboxes. And training admins to regularly use source control has proven a challenge over the past few years.
Most teams today are either: a.) Not using source control at all. Or b.) Trying to set up Ant scripts to do a weekly backup of changes into Git. The problems with a.) are obvious. The problem with b.) is that you don’t get very good data. We spent our hallway conversations demoing our forthcoming Salesforce DX integration with Blue Canvas. We showed our customers and friends how you will soon be able to spin up a Scratch Org with the Blue Canvas UI. You can then populate Scratch Org with metadata from your Sandbox and use it as a feature branch for development. When you’re ready you can then merge the metadata back into the Sandbox just as you would with normal branches. We got good feedback from showing our demo and we’ll be posting more about it soon.
Admins and Source Control Many teams were eager to swap ideas about getting admins and less technical team members into their source control. The great thing about Salesforce is that admins, business analysts, project managers, contractors, consultants and others can all make changes to Salesforce. But this makes it hard for any developer to get their team trained to use Source control.
Most teams today are either: a.) Not using source control at all. Or b.) Trying to set up Ant scripts to do a weekly backup of changes into Git. The problems with a.) are obvious . The problem with b.) is that you don’t get very good data. When you use Ant to push all of your code at once, you don’t get detailed updates about changes, you don’t know who has changed what, and you cannot roll back to previous states.
The goal of all this setup was to improve efficiency through automation. And yet, teams were failing because setting up CI with Git and Salesforce still required a lot of manual steps. People seemed to like our solution of having automatic commits to Git whenever an admin makes a declarative or code change. This allows admins to get the benefit of source control and CI without having to train them anew. It also gives you more granular commits that helps with auditing and Sox compliance (more on that later).
Simplifying Git Flow and CI for Salesforce
More teams are seeing the benefit of continuous integration and delivery and quite a few have corporate initiatives in place to get source control and CI for Salesforce in place in 2018.
We had a hallway conversation with 4 or 5 Salesforce teams of various sizes that all had a similar problem. They were working with Ant scripts and external CI tools like Jenkins and TravisCI. They were using GitHub or Bitbucket. They were doing their best to follow the Git developer flow for Salesforce . These were smart teams with lots of budget and talent. And yet they were not finding the right flow for Salesforce development. Not every member of the team was finding Git intuitive. Not everyone was remembering to strictly adhere to the process.
The goal of all this setup was to improve efficiency through automation. And yet, teams were failing because setting up CI with Git and Salesforce still required a lot of manual steps. Before deploying, you had to remember to check into Git. You needed to get your code and metadata to Git. This is challenging depending on what type of metadata you are trying to move. Email Templates, Apex Classes, Profiles, Permission Sets, Workflow Rules, Triggers: all have different challenges, dependencies and requirements. Once someone pushes to Git, then you have to deploy. Deploying cleanly is a pain because of said dependencies. If someone’s Email Template changed by an admin and that was not committed into Git, the Apex Class that references might not deploy cleanly.
So many teams are struggling with this. Sending code from Salesforce to Git and back. It’s really painful. We showed teams what we were doing to make Git an afterthought in the Salesforce development flow. By tying your Git repo more closely to your orgs in a hosted service you no longer have to do the manual steps that teams are struggling with. Blue Canvas does continuous automated commits to your repo. So there is never an issue where Git says something different from the orgs. This makes Git and the org simultaneously a source of truth and allows for cleaner deployments.
Many teams are trying to do the right thing by bringing a Git flow into Salesforce. But because of Salesforce’s unique value proposition, there are parts of Git flow that are just too complicated or superfluous; that create more chaos and bureaucracy than value. It’s also useful because it makes it easier for admins and less technical people to be included in the developer flow.
A Sandbox for Each Feature Release
We got into a really interesting conversation with a large enterprise Salesforce development team. “Should each developer have their own sandbox? Should they have multiple UAT and staging environments?” they asked.
We ended up coming up with a solution together that made a lot of sense. You could feel the excitement in the room as we brainstormed the idea more concretely.
“What about having a Sandbox for each release?” one of us said. “Whether it’s a monthly release or weekly or quarterly just setup a Sandbox for that release. Have developers use their own developer orgs and sandboxes for creating features. Have them continuously deploy small chunks of metadata to this release sandbox. You can then handle all merge conflicts, dependencies and issues here. So your release sandbox is always ready and could be deployed at any time. You can also do really good testing here. Once the release is ready, you can simply deploy the release sandbox straight into production. This keeps things very simple.”
Everyone’s eyes lit up. Many teams are trying to do the right thing by bringing a Git flow into Salesforce. But because of Salesforce’s unique value proposition, there are parts of Git flow that are just too complicated or superfluous ; that create more chaos and bureaucracy than value. We learned in our conversations that there is probably a new flow that needs to be developed for Salesforce. We’ll post more on this soon.
Audit Trails and SOX Compliance Salesforce has arrived. It’s a full-fledged software development tool. And as such, SOX compliance and its requirement of separation of duties and audit trails came up a lot in conversation. Many teams are looking for ways to get more data on what is happening in their orgs. This is especially true for teams that leverage the benefits of professional services or consultants. Automatic commits to Git were very appealing for teams that were struggling with this. Many of our customers use us just for this purpose alone.
Less Discussion of Einstein and Lightning Many of the Salesforce demos are now done with Lightning, and Einstein had over 40 sessions dedicated to it. Still, there was less buzz about these than DX. Admittedly we might be hearing a biased sample given the nature of our product, but it was interesting. Maybe people are still waiting for more concrete benefits from Einstein.
myEinstein seems interesting and promises to allow Salesforce developers to “build smarter, more predictive apps that leverage their Salesforce data and solve their specific business challenges… So everyone can have AI that’s customized for their business, without needing a data scientist.”
myTrailhead Salesforce is really great at turning internal tools into customer features. myTrailhead is an exciting new recognition that a huge part of customer success is training. Salesforce is innovating in a really practical way here. It’s not as flashy as AI or machine learning or IoT, but making customer training more accessible will have a profound impact on customer success. We are excited to see how this develops and so were many of the people we talked to.
