Salesforce DX has enhanced collaboration, quality control
In 2017, Salesforce rolled out Salesforce DX, a tool to enhance the Salesforce development process. In this episode of Q&A Friday, we sit down with James, our Senior Salesforce Developer, to review the platform and share how DX has changed our development workflow. James outlines the benefits of DX including how the new tool can improve workflows, facilitate collaboration, and ensure quality control.
Have a question you’d like answered? Let us know in the comments, and we’ll talk through it on a future episode!
Episode Transcript:
Jessica Vodden: Hi and thanks for joining us for another Q&A Friday, a regular series where we chat about issues facing manufacturing companies who are undergoing digital transformations. I'm Jessica Vodden, a team member here at Mountain Point and I'm joined by Andrew Rieser our co-founder and president, and James Boggs, one of our Salesforce developers. Hey guys.
James Boggs: Hello. Happy Friday.
Jessica Vodden: Happy Friday. So today we're going to talk about Salesforce DX, which is a relatively new tool that has really improved the development process for folks who are working to customize the Salesforce platform. James, that's why we invited you here, you're our Salesforce DX expert and use it the most. So let's start with the basics. What is DX and who tends to use it?
James Boggs: Well SFDX that's the Salesforce developer experience. It allows you to isolate the project that you're working on from the rest of the context of the org. You don't have to manage everything in the org like would with a regular sandbox. You can just have the piece that you need to work on all by itself in a scratch org.
James Boggs: So Salesforce DX, it makes code.... Your developers code is the source of truth, right? So even the Metadata, like the names of your fields and the custom objects that you're going to work on, all that stuff is represented as code. And you can save it in your GitHub repository or the version control system of your choice and you can use it to generate new scratch orgs or you can use that code to push new metadata to your sandboxes or production orgs. And everything is represented in code which means you can always keep track of who changed what and when and for what reason - in your version control system.
Jessica Vodden: Okay. So definitely a quality control sort of system then.
James Boggs: Right.
Jessica Vodden: So what do you think are the big benefits of having DX?
James Boggs: Okay. So the benefits of using DX are, I mean there's a lot of benefits to using DX. It doesn't a little bit of overhead and the time that you spent, but the benefits are pretty big. So it makes it a lot easier to use version control, like Git to track your changes for one thing and the other is if like in the instance of Richwood, the customer is really involved because we're using their GitHub repository to store each different project that we're working on and we start each one and its own repository. All those things are separate and the customer has access to that GitHub repository. They can get in and they can track their issues that they're having with the particular project right there. And that comes directly to my desk for one thing and in a way that we can track against. In a way that with there we're all quickly updated about the status of the issue or a new feature.
Jessica Vodden: Okay. So definitely a good collaboration tool then.
James Boggs: For sure. It also makes it a lot easier if you have multiple developers working on one project. Everybody can get their piece and put it in their scratch org and then they can all merge together into a parent scratch org or into a sandbox or move on to user acceptance sandbox.
Jessica Vodden: So what is the difference because I'm definitely not a techie person. What is the difference between a scratch org and a sandbox?
James Boggs: A sandbox is kind of a full picture representation of the production org. Every custom object that they have, every process builder, every workflow rule, everything is in the sandbox. Not necessarily all with their data, but all of their processes and all of the overhead and all of the conflicts that can happen because of all those processes working together. In the scratch or you just need the thing that you're working on. Your new process builder or your new trigger. You just need just the objects that you're working on and you can easily create a scratch org it was just that stuff that you need.
Jessica Vodden: Okay. Super cool.
Andrew Rieser: James, just for context as it relates to these scratch orgs --- because I think it's a fascinating concept and the technology behind it --- so for all the Trailblazers that are out there that are taking trailhead, learning modules, essentially when you are in a learning module, earning your badges, that's a demonstration of scratch orgs right there, right? So it allows you to quickly spin up an org that's specific to the trail that you're completing. And it kind of checks and validates the metacode like you're describing to validate successful completion of the course. Is that right?
James Boggs: Yeah. It's very similar to the Trailhead orgs.
Andrew Rieser: And kind of along those lines, this is where I'm intrigued. I think that the more that you can kind of create these bite size chunks through these scratch orgs and leveraging that exchange that you had talked about, that we do with one of our customers through git hub. I think that creates a more kind of pinpointed quality control aspect of these projects too. So that you don't have to go through all these massive test cases and scenarios and all that. It's those pieces are also broken down into the bite sized chunks which makes it the quality of the product turn out better as well.
James Boggs: Right. That's a trend and always has been in software development. That's the whole process. You take your big problem and you break it into small problems and then even smaller so that any given task isn't a monumental obstacle. So the more pieces we can break the process down into, the easier it's going to be to compile a solution.
Jessica Vodden: It sounds like this is a much better fit, this sort of system with the agile framework that most people use now. It kind of sounds like previously we were operating on tools built for that waterfall development process and it is more agile solution.
James Boggs: It is a more agile solution. We can respond instantaneously to anything that comes up and we can track everything all the time. And if something was to go wrong and because we're using version control, we can revert quickly because we have the complete history and everything that's happened.
James Boggs: That has been pretty excellent. The fact that we can work like for instance with Richwood were we can use the GitHub repository to get it together directly without stuff getting lost in email and things of that nature. Is that if he has an issue that comes directly to me and if I solve this issue that goes directly to him and all that stuff is tracked on a big board and we can work together to more quickly come to the solution that they need.
Jessica Vodden: Tell me, kind of give me the background of what you're doing with Richwood.
James Boggs: So for Richwood we created few, we've done a few projects using Salesforce DX so far. One of the big ones is essentially their sales forecast application that they've developed. And so we created a scratch org that just has the objects that they record their sales forecasting stuff in. The accounts and the customization to accounts and then custom objects that keep track of what's the forecast for this customer for this period of time and et cetera. That's the stuff, that's all we need in the scratch org. And we use Git and the customer's GitHub so that he can say this, when I did this, we had this bug and he can send that issue. Put the issue brought up on his GitHub repository for that specific project. And I can say I'll get to this and check it off and he can be updated immediately when that happens and I can be updated immediately when he adds a new one.
Jessica Vodden: Okay. And so does this get you around any of the issues? Like I know anytime that I've ever worked with a tech support person or a development person in the past and I'm saying I'm having this problem and we have to go through this whole process of trying to replicate it. Right? Does this give you insight into that issue that's going on without having to go through that testing phase again or no?
James Boggs: It does help in that you're new project, your new trigger or whatever is working in isolation, right? So in a sandbox sometimes it's difficult to tell if the bug that we're going to see is because of the new feature or if it's because of some unforeseen interaction with another feature. So in the scratch org we can just work on the thing we're working on. Right? Then those kinds of issues don't exist until we merge it into with the whole context of the sandbox, we have everything else. And then we can definitely say at that time our new feature isn't the problem. It's the interaction between the new feature and the old feature. So it does help pinpoint those issues.
Jessica Vodden: Okay. That makes a lot of sense.
Andrew Rieser: So what's cool and exciting for me is I can see this being applied across all of our customers. So I'm excited to see how we take these couple of customers that we're currently doing this with and bake more processes around that so that we can introduce this with our other customers. Because in my experience, the same challenges occurred and I think we've talked about it. It's all the gather a whole bunch of requirements, build out a whole bunch of things, but because it's so broad and long and that kind of even though we try to be agile, it still tends to be somewhat of a hybrid approach for development. And I think that this kind of will become a great toolbox, or a great tool in our toolbox to kind of incorporate as a part of our best practices moving forward.
Jessica Vodden: Very cool. James, what's the thing that got you the most excited when you first started using the DX? What were you just like, “This is really awesome!” about?
James Boggs: I think the coolest thing about Salesforce DX is that they have the new SFDX command line interface and that's really awesome. I can create a new scratch org and start development on a new product or a new feature by typing in two commands into a terminal. It creates a new org. It creates a new user and a new org to my specifications and I'm ready to go in, like 15 seconds.
Jessica Vodden: So what was the process like before this existed?
James Boggs: You have to, it takes like 20 minutes to create a new sandbox. You have to go into your production org and go to your sandboxes management tool and see if you have a sandbox available to create one because there's limits. And then you have to know if you need data then you'll have to create a partial or a full sandbox and that could take an hour. So with Salesforce DX I just tap a few things into the terminal and press enter and I've got a new org to work with.
Jessica Vodden: That's awesome.
James Boggs: It's pretty sweet. Like I said, it is a little bit more complicated sometimes and the complicated part is just getting the stuff that you need from the production org like the custom objects and stuff like that, port it over into your scratch org, you don't need the whole thing. You just need a piece of it and then you work on your thing and is what makes it a lot simpler to spot things like for instance with Novacopy [now Novatech] we've got stuff that does not work well together. And finding out what thing is causing a problem with a totally unrelated thing. Or seemingly unrelated thing that gets complicated.
Andrew Rieser: Right. I think you hit the nail on the head. That's exactly who I was thinking of is how do we have that audit and kind of documentation that shows what we put in place is not the issue, but there some either downstream or effect outside of what's developed? Because especially in larger more complex kind of development projects. The kind of analogy that we often hear and kind of back and forth with our customer is the whole whack-a-mole scenario. Right? So this issue came up and we thought we solved it, but then we reintroduced to another series of issues and being able to really pinpoint that to validate, no, that's not accurate. This is a completely different test case or scenario that you're bringing up and has nothing to do with what just got deployed earlier or something like that. I think that also will give customers more comfort and being able to see that and trace that.
Jessica Vodden: Awesome. James, thank you so much for taking time to chat with us. It's really fascinating to hear about the work that you do because it's for me at least pretty removed from my day to day. And so I just loved hearing some of the exciting work that's happening on the development front and I appreciate you taking the time to kind of walk us through all of that. For those of you watching or listening, if you have a question you'd like us to answer or a topic you want us to tackle, let us know. This is a chance for you to get free expert advice and insight and there's no obligations on your part. You just want to send us an email or hit us up on social media and let us know what's on your mind. Will try to talk through it on a future episode. So thanks again James and Andrew and happy Friday.
James Boggs: Thank you.
Andrew Rieser: Thank you.