In today’s episode, I talk with Christian Menzinger about his experience with SalesforceDX. He addresses the specific pain points he has been able to address using SalesforceDX, especially the Salesforce CLI. Christian describes a lot of the flexibility and functionality that comes with the tools that can help both admins and developers..
Christian is a freelance Salesforce trainer, developer, and consultant in Germany. He is also a co-leader of the Munich Developer Group and the father of two boys. He has extensive experience with and knowledge of SalesforceDX. I’m confident his tips will be very useful for all of us.
Show Highlights:
- How to make developing easier with multiple developers all working on different branches.
- How to maintain a large code base.
- The benefits of unlocked packages.
- Why dependencies are so crucial and how to untangle them.
- The pain points Christian has resolved using SalesforceDX.
- Time-saving plug-ins and where to get them.
- Christian’s experience co-leading the Munich Group in this interesting time.
Links
Episode Transcript
Christian:
So I knew that in DOS, you had to edit the config service and Alta exec back to get more memory for your games you want to play up to high new, a little bit of command line. And then when Salesforce dx was announced the skill is a big part or is one of the big tools we got for development. And so I get into the Seelye, the Salesforce CLR. And I really love it right now. So I use it every day I use a couple of times on different jobs also not only on desktop development also for private things.
Josh:
That is Christian Menzinger, a freelance Salesforce trainer, developer and consultant over in Germany. I’m Josh Birk, developer evangelist for Salesforce. And here on the Salesforce developer podcast, you’ll hear stories and insights from developers for developers. Today we sit down with Christian to talk about his experiences with Salesforce DX – starting with a little bit of advice for people who might not be familiar with it.
Christian:
Yeah, definitely. So first of all, Salesforce DX is not an all or nothing option. So you don’t have to follow a certain path and have to adopt the CLI and have to adopt unlock packages and scratch with everything. So I would always recommend, look at your current development workflow and mark out what are your biggest pain points? And then you can start to think about Okay, if, for instance, a pain point is that I’m overriding one developers overriding the changes from another developer, then you definitely should go for like source driven development and adopting scratch works for everyone has its own environment. But as I said, you don’t have to start with under package at the very first beginning you can just see each and every part of this tools and paradigms and best practices, what fits into your environment. It’s also totally valuable to say okay, we use source driven development. We Develop on a scratch rug, but then we deploy to our UHT sandbox or to our full copy sandbox. And then we do change sets to deploy to production. That’s totally fine. But when you, for instance, already use change sets, you could also use unlock packages, because nearly everything what you can do with change sets can be done with unlock packages. But it could be on the next evaluation step, for instance. And in my experience, most of the trickiest part is not technical things. It’s more about getting everyone into the same mindset. When Christians talking about source driven development. He’s really talking about something of a major transition from org centric development where you have some kind of developments or sandbox, which is your source of truth versus using a repo. And there’s various tricks that you can do using scratch works to make development easier. So typically, you have one scratch out for one branch. every developer works in a separate branch. has his own schedule. So I worked at a company, I had a customer and they used one developer or for all the developers, and it happened quite often that changes have been overwritten on a developer front, from changes from another developer. And this is, of course, the worst case. That’s something you really want to avoid. And that’s the reason why the scratch work is very tied to your source, what you’re developing on. And so it’s easy to just compare two branches. For instance, you spin up to scratch rocks, and you see if you have the same behavior or so maybe you have a user who can double check if there is changes, or if he makes an A and B test to say, Okay, oh, this is much easier than that one. This is all about strategy about what you do in your code repository, how you branch your features, and then you can never scratch. You can automate this of course, and just have someone testing your stuff. saying, okay, your product manager, for instance, the product owner saying, Okay, this is cool or we go for that way we go for this way.
Josh:
And moving to a different portion of Salesforce DX. Have you found tools like unlock packages it to be useful when maintaining a large codebase?
Christian:
There are two things in your question that one is useful. Yes. The second one is in a large code base, which makes it tricky.
Josh:
Gotcha. Give me a little bit of detail on that. What kind of experiences have you had?
Christian:
Yeah, so I started with a customer. And so they had already some development going on. And we started kind of a Greenfield side project. So we did not have a lot of dependency on the existing code base. And so we add up another package for the new stuff. And that worked out very, very good. So it not had a lot of dependencies. We just built the new stuff on top of the existing one, we create a package over there, we install the package and we also start Using under packages for the other projects, which have been already going on in the past, and so we had some interdependencies where we just moved into a base package. And so I think the default way on how you could solve this, okay, yeah, it’s getting complicated, the larger the code bases going. So the problem is always, if you have, for instance, if you’re mixing different automation tools, process builders here and workflow over there, then you have a trigger over there. And so you will have dependencies all over the place. And so the bigger the code base gets, the more separation you need. And so, you want another package the idea is that you have like of separation of concerns, you have one pack, which has a dedicated role in your system. But the problem is, they all depend on for instance, schema, they all depend on different other process is for instance, and so the bigger and the more expenses, you have The harder it’s getting to untangle these dependencies. So that means it’s not only unlocked packages, what you can adopt. So you also have to think about, like maybe implementing, like dependency injection to untangle your dependencies or using the price patterns. So our software architectural patterns to really separate different areas that you can easily use an unlock package. And there is also a gap, and the packages are fine. But not all metadata are yet supported, though there. Right. So there’s the crate metadata coverage report where you can see which metadata is supported for an unlocked package. And I think the gaps are getting smaller, which with every release, but there is still some uncertainty that everything can be used in an unlocked package when you have a bigger codebase. And as I said, dependencies are a very crucial thing. Now with the summer release with this release going on right now, you have this org dependent unlock package, which is better right now. So it’s in a very early stage. But what this does is actually, that you can say, Okay, I’m only developing for my production org, but I have some dependencies, I can’t get rid, I can’t untangle it two separate packages. So I just need this dependencies somehow resolved. And this is actually we’re all depend on the packages come into the game. On the one hand side, this is great, because now you can easily create this dependency package and you can get your things done. But on the other hand, this is kind of saying, Oh, we know that we have gaps. And we know we cannot solve this API gaps quite fast. Please use this box dependent Hello package in the meantime, because not everything can be untangled right now. Right? Right. And love packages have been introduced two years ago, I think. And so that’s about right. There are some still some gaps, but I mean, that’s okay. I mean, there is a lot of legacy code everywhere. So I think the same is true for Salesforce.
Josh:
Yeah. So I think to kind of paraphrase that tip, well, at least part of that, to a certain extent, is it sounds like some, you know, when you when you start getting into a larger codebase, like that, one way to remove some of the pain points of things, like, unlike packages and maintaining that code is, is to plan ahead, right, because you’re talking about things like architectural patterns and separation of concerns. And then that starts at the architecture level before you know how you’re going to code the things not actually the code itself.
Christian:
Absolutely. And as I said, You bigger the code base gets, and also your more legacy of code base. You have, of course, I mean, I when I talk about code base, I only mean Apex and maybe lightning components, all that stuff. I mean yourself. org Which is all kinds of metadata, which is my water and I’m talking about the code base, right? And so yeah, as I said, the larger it’s going, the more tricky it gets. And one thing for sure, when you start in a smaller org, and you start, and maybe you’re interested in Salesforce, DX and best practice, so you definitely should adopt going for unlock packages, because it gives you a way to structure your org from the beginning. What it does is actually for instance, when you go to the setup, and you have a look at the custom fields, if you have an under package, this field is part of an under package, you will see a yellow information that this field is part of package ABC gives an admin an idea, okay, so this field is part of project ABC. So maybe I’m talking with the product owner to get more information about this field or whatever you find in your so it just gives you a label to say hey, I’m part of Have a separate package. And maybe you have a dedicated project owner for this package. It makes it easier when you’re all crews. So we have different separated labels, I would say, to mark certain parts of your work to be part of a certain process or certain package.
Josh:
Yeah. So that’s interesting. So not only on the design side of things, but because it’s a distinct package you have, I almost hesitate to use the word meta because we use it so much with Salesforce, but basically a metal layer of information about that functionality within an object itself.
Christian:
And unlock packages are quite flexible. So they’re really great. So for instance, you start small, you can iterate and you can undo everything. So that means you start with the package and you put, I don’t know everything into one package. And at a later point, you say, Oh, I have a dependency to maybe another package, I need a base package. So you can just remove metadata from one package, and now it lives a separate package. So you can move it around, you can remove things from one package, put it into another one. So you’re flexible. But it gives you the advantage that you have versioning. You can really have dedicated package versions, you can roll back in your codebase, you can create a new version with the help, you can create hotfix, all that stuff. So it gives a chance more control. It’s not only like unstructured metadata all over your production or right, fractured back. And then you have full control about the lifecycle of this package,
Josh:
which is, you know, going back to the, shall we say, good old days that that’s giving you the flexibility that unmanaged packages didn’t have that without all the weird restrictions that managed packages did.
Christian:
Absolutely, absolutely, that’s exactly so you get the best of both worlds from unmanaged to manage package. So never use an unmanaged package if you really want to use it as a like deployment container and you want it right Because of an unmanaged package, you have to uninstalled and all your data, everything is lost when you have a new version of the unmanaged package. So this is really kind of something you don’t want to have. On the other hand, if you build a managed package, you have a namespace and you have a lot of different restrictions you have to take care of. This is also a burden. In most cases, if you just build for your production, or you don’t want to go there, right? And not packages, giving you really the flexibility. So you can remove things. You can upgrade things you can install, like a normal package, but you don’t have to uninstall when you introduce a new package version.
Josh:
So let’s get back to the concept of DX and see ally as being kind of a very specific tool for solving problems. What are some pain points that you have resolved using Salesforce DX?
Christian:
When you talk about Salesforce dx, you have to specify what exactly do you mean
Josh:
let’s go back to the CLI.
Christian:
Okay, because in my opinion, Salesforce DX is just an umbrella term, it’s kind of a product, it’s kind of means so many things. And when you ask two people, you get three opinions what is. And so when you say, OK, which complex when you can do with a CLI, at least everything because if you have source code on your machine, you can transform the source code, you can modify it, you can use not only Salesforce commands, you can also use different commands which are from, from the operating system, for instance. And what I’m always do is, I always have a create scratch work script, because when I start a new project and you create a new scratch hook, do you have always do several steps to establish your working environment, right? scrapbook you have to push your source you have to assign a permission set, most likely, then you have to maybe import data, you have to maybe enable the debug mode if you do lightning web components. They’re a little separate steps. And so this is actually a huge time saver. So I just chain all the commands in a bash script. And then whenever I need a new scratch work or my manager needs a new scratch up because he was interested in what’s going on right now I say no worries. I let the run script run, I give you the credentials, log in and play around. You can’t break anything. It’s your org. Just do whatever you like. And so this is great power. And when you get deeper into what you can do with Salesforce COI, you can execute anonymous Apex you can query using sub queries, you can get the response as chasen and there are great J’s libraries, for instance check you that you can work with so you can really really fast working with data and was metadata because it’s all textual files. And with the COI, you can modify text files very easily.
Josh:
And so talking a little bit more about that flexibility. What is the role of plugins when utilizing the CLI?
Christian:
A huge role. What I really love is there is a community around and as the CLI has a mechanism that you can create your own CLI plugin. So it hasn’t built in plugin creators, you just say plugins create, and then it’s just start and dialogue. And you can extend the existing COI with your own. And this is really great because there are so many different aspects in Salesforce development, everyone has a different angle, you’re the partner of your customer, even if you take two ISV partners that have maybe different requirements. And so with the power of the community, things can build, which self was maybe don’t have the focus on. I give you a good example. So a couple of days ago, I wanted to extend a little bit of existing code for a customer. And so I wanted to deploy this to my scratch org and it says no, it’s not working because of this and this error. So it pointed out that I need to enable shared activities. I had no clue about your activities in the past. So I googled a little bit and I found out okay, shared activities is not exposed through the API. So there is no chance to make an automated build for a new spreadsheet, because I have to click this one button in the setup and say, confirm, write API for that. But then I found the plugin, which is actually automating this step. So they’re just using Google puppet here to say, okay, the pattern gets clicked for me and I can just chain I can use this command in my build script. And now I haven’t full automation again, for this certain behavior, and there’s it’s just a small little piece, right but if me some time, and if you have a look at all the existing plugins, there are a couple of thousands around and every plugin is solving more general purpose or very specific purpose or issues. And there is a great repository From Shane mcglothlin, which is also Salesforce employee, because he has a awesome plugin repository, which is just a collection of all the different plugins from the community. So it’s a huge list. It’s a growing list
Josh:
nice.
Christian:
And one of one of the one things which is a little bit sad is that there is no central marketplace like the app exchange for Salesforce CLI plugins. So right now, you don’t have that centralized repository where you can just say, hey, has someone else solve this issue right. Now this repository from from Shane is quite good. And as I said, maintain so also the community popular, distributes some new plugins there. And it’s definitely worth looking at the list because there’s so many powerful things. For instance, if you have ever tried to convert a profile into a permission set, this is painful, john, but there is a plugin for that which exactly does this one It saves you a lot of time. Nice. We will definitely link to Shane’s repo in the show notes for anybody who’s listening. And I also that’s the plugin you made an example of, that’s really kind of fascinating to me because you have a CNI plugin, which is manipulating a desktop browser. Like, that’s, that’s pretty cool that there’s that level of flexibility in the things that you can do using the CLI.
And it’s not only about the CLI, it’s also about if you have the source code or the metadata code, I would say. So just give you another example, which is a very common task, but it can be achieved much easier in in source code in the XML files of the metadata rather than in the setup. So for instance, I don’t know you have a list, you have lists to use for your opportunities and someone introduces a new field. And you want to have to show up this field and all the I don’t know 10 different list views. So you have to go to each and every list. You say at it. You have to field you have to get safe. But when you look at the metadata, it’s just one note in an XML file. And I can easily copy and paste this into all the several places. And this job can be done in, I don’t know, 30 seconds, maybe, you know, I trusted your back and was done. And maybe another tip on the side, whenever you start working with Salesforce metadata on your machine, be sure to use the source format. Ahmed has also been introduced with Salesforce dx. And it’s a different I’ll just say it’s different structure, structure. Thank you. It’s it’s not that monolithic XML structure. So it breaks down into several XML files. And it’s handy, especially for version control, especially for when human reads it and wanted modified, like adding a few to the list view in the early days when you have the metadata for an object and then there’s just one section for this to use in that huge giant XML file, but it was the source format. It’s just one XML file for each and every list view. And so it’s easy to maintain or adopt this requirement, saying, hey, I want to add this field. And you can convert classical metadata into source format. So there’s a command that the CLR just converted from one format into the other. So if you have already started working with source on your, on your machine, just converted and put the version control, which makes it much more easier.
Josh:
That’s our show. But now before we go, I did also want to ask Christian about his experiences of being a co leader for the Munich user group, because we are, after all, recording an interesting times, which has shifted their strategy a bit.
Christian:
Yeah, we had the same discussions how or at the beginning, we didn’t know how long this whole situation will rest. Maybe a remote just having like a webinar. We don’t like this idea because we don’t feel as a content provider. We really want to engage with the community and it’s After a while, we said, okay, we will not go for normal meetups in person meetups quite early. Yeah. Okay, let’s do a virtual meetup. But let’s try to really engage the community. So what we did is we said, okay, please everyone turn on your webcam, we want to really engage also if someone is presenting so in the classical webinar, you just post your question in the chat panel, and then it’s getting read by one of the moderators and answered by the by the speaker, but we said, okay, just raise your hand. And so we use zoom feature that you can raise your hand. And so whenever someone raised their hand, we call him by name, and so he can unmute it, you really can talk and interact with the presenter. And also after every talk, we have discussion, so we try to have free speech, of course, a little bit of moderation because if 10 people start talking at the same time, right, notice not working very good, but We found out that when we say okay, please raise your hand or write into the chat panel and we will call you by name. And then we really had a good discussion. We also utilizing, like pause to engage the people, we also try to make it a little bit more interactive. So I would highly recommend to really try to engage everyone. When you have a smaller group, it’s easier, maybe 10 to 20 people, it’s maybe okay that everyone just can start talking if someone has a question, but at a certain point, we have too many people, you have to organize a little bit. What we did also is we had a slide and slide at every meetup we do virtually now is giving you some tips about using zoom because everyone is used to it so like for 49 different tiles on your screen. So if you have a second monitor, you can really see 49 people at a glance which if you like More community feeling if you’re not, if you not only see the speaker, you see all the known faces from in person meetups. And so we gave some tips about, Hey, don’t be shy, turn your webcam, use the settings, zoom, we use this feature, raise your hand, all that stuff. And altogether I think we received very good feedback. And looking forward for the next one, I think in two weeks or so,
Josh:
finally, like so many people out there, Christian’s favorite non technical hobby includes entertaining the kids.
Christian:
I have two boys, very, very active boys. So they all always want to be entertained. I mean, fortunately not. They do really good also during this time, so they can really do a lot of things by their own. But it’s always fun. If we go somewhere I don’t know for hiking the Alps or go for I don’t know, stand up paddle somewhere. So we can have different things we do and be outside be active. This is actually what I really love.
Josh:
Thanks for listening, everybody. And thanks Christian for the great conversation in information. If you would like to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again and I’ll talk to you next week.
Transcribed by https://otter.ai