Nicolas Vuillamy, who joins to talk about Sfdx-hardis, is an open-Sourcerer and CTO in Cloudity.
Main Points
- Nicolas’ MegaLinter open-source project
- Nicolas’ Sfdx-hardis open-source project
- Why should we use Sfdx-hardis?
- Is it easy to learn and start using Sfdx-hardis?
- Roles: contributor, release manager, setup manager
- Source-code based strategy
- The Vscode extension
- The sfdx plugin feature
- DX@Scale, Sfdx-hardis, 3rd party proprietary tools, and DevOps Center
- What metadata types should be part of DevOps pipeline
- The deploy-all approach in Sfdx-hardis
Links
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:14] Hello, everybody. This is Xi Xiao. This is yet a new episode of Salesforce Way Podcast. Today, I'm sitting with a new guest. His name's Nicolas Vuillamy. Hello, Nicolas. Would you like to quickly introduce yourself? Why not? So, so my name is Nicolas Vuillamy. I am CTO in Clouditi, who is a Pan-European Salesforce integration partner. So we are mostly middle market, but we, as we are growing, we aim to. To have more and more big clients soon, and and this is my job during the day. And during the night, I do a lot of open source. Around Salesforce, but not also, but also around code quality. So I am also the author and maintainer of Mega Linter, which is basically you can install it on any project in any technology, including Salesforce projects, and it will detect lint, code quality issues, code smells, security issues, etc. So you just mentioned you do open source in your spare time outside work, right? This Mega Linter.io, that's one of your. Your babies, basically, right? Okay, babies. I prefer seeing it as a community project now because I have more than persons who contributed to the repository compared to the Salesforce RDS. It's a lot. The Salesforce RDS. It's only thirteen. But when you start an open source project. It takes time, and what you want is to have more and more people also working on it, adding new features, sometimes fixing fixing
[01:44] bugs, and so you don't have to do everything yourself. I think an application that is understood only by one person is not valuable because the day this person gets hit by a bus or abducted by aliens, who will who will manage the maintenance? So, I like I like to see open source projects, especially the ones I work with, as community projects more than Nicolas Vuillamy's projects. Hmm. But which one now is more popular and with more contributor? You have the Mega Linter, and you also have this SF DX Hardys that we're going to talk about in this episode, right? The more popular is Megalinter. Today, it is it is used all around the world by big companies. I recently discovered that the NSA, the real one, was using Megalinter on an open source project. Also, the CERN in Switzerland, the English Ministry of Justice, AWS, Google. So okay, okay, okay, it's growing, it's growing. But it's easier because it addresses all ecosystems, whereas Salesforce Certified, it is just for the Salesforce ecosystem, which is smaller. Maybe already a bit off topic. Now I know what Linter is for language, but I never used the Mega Linter. It's like a similar things it does. Yes, it is. It is embedding a lot of linters. Probably the ones you are already using individually. Okay, so you kind of like combine the ones, and it's a umbrella. Yes. For example, it embeds the SFDX scanner,
[03:15] which is a SFDX plugin. Who itself embeds the PMD, SLint. Ah, okay, okay. That sounds good. Okay, I'll also take a look and put the link into our show notes. So this episode, I want to talk about the hardest. That's one of your other babies now, as the community contributions, but the. It's more all for DevOps, right? In Salesforce, it's to helping the companies to manage the DevOps task. A part of it is for it. It can do a lot of more more things, but but yes, the main usage is to have ready to use CI/CD pipelines and tooling to make for to allow anyone to work on the CI/CD project, depending the people are admins or developers. And and also it is what is nice with open source. It is free, so so that's why it can have some success because it may be less advanced on many points, especially UIs, than other building tools. But but the gap of the pricing can be considered big enough for many people to to choose the open source and production ready and proven solution. You know, I had the initiative to engage with you because I was working with Lel Yokinen. We were working in the same company. I know he contributed into this project. I have not talked with Leo about what he really thinks
[04:45] is good, but maybe you can give a quick pitch to me why people should really use it. Yes, sure. First, I would like to to thank Leo for talking to you about SFDX RDS, and also thank him because he made a huge contribution to SFDX RDS because. Initially, it was working with GitLab and Azure, and Leo liked it but wanted it for GitHub, so he implemented himself. The compatibility with GitHub, so so it is a good example of I can start something which is continued by other great people, and and Leo is one of those great people, and and how can I sell sell something with no price? Basically, today the first the third point. Is to make anyone understand that org-based deployments, meaning change sets, meaning click deploy, meaning the simple version of gearset, it has to be over because when you work directly with orgs and no git, you have no versioning. You don't. You can test something in a user acceptance test environment. And then make a deployment in production, and you are not insured to have the same metadata, so to have the same results. So basically, today with Salesforce, even if Salesforce has has absolutely not been made for DevOps, really it's DevOps with Salesforce. It's awful. When you did DevOps with other technologies, you see DevOps
[06:15] with Salesforce. But but basically, you you have two ways to do DevOps with Salesforce. You can use the third party tools like Salto, Copado, Gherkin, Totorabbit, Opsera. There is a lot of of great products. And if you are working mostly in middle middle market like like me and Cloud IT. Sometimes it can be difficult to tell clients, "Oh, you have to pay dollars by month by user, sometimes more." Just for deployments, so the second option is to script yourself the devops process, but to do that, you need. But you you need to have someone with. Big knowledge of DevOps and Salesforce and the AppExchange and Metadata API. You have to script a lot, a lot, a lot, a lot. And if you are working in multiple projects, those scripts you will have to copy paste them and maintain them, and it can be quite boring. And it is what we started to do at Cloudity, and it worked very well because we have people knowing DevOps. We will know how to make a useful CI/CD pipeline, but we didn't want to maintain long Bash scripts, YAMLs, etc. in Our hundreds of projects, so we decided to package the scripts, so they can be they can be maintained at only white one place, and you don't have to basically you can focus your time on really deploying and working, and not scripting the stuff for deployment on each project.
[07:45] And as we did it for all our internal projects, and we saw that it was working, we decided to expose it to the Trailblazer community. So, so first, to be nice to people, because we use often open source tools like SFDX Git Delta by Sébastien Colladon, like SFDMU by Haim Nof, like Text Plugin by by Fabien Taillon. And so, as we use the other plugins of people, we say, why not sharing ours? And and I like the result because the result is someday a guy named Leo or another guy named Roman in Germany. They say, Oh, we we want that, we want this new feature, and we implement it. And so by sharing our work for free, we benefit from the work of others, and it's it's it's what is what is really nice with with the Trailblazer and open source community. Hmm. Maybe I drifted a little of your initial question. Yeah, it's okay. You tell a high level picture what it is, what's going on. But to me, I don't have the chance, or I didn't put the time like Leo or other contributors to really study the core part. What's what's the logic? What's the patterns underneath? As a user, if I just want to grab your solutions and start to use it, is it possible? Is it easy? Yes, because we we have a full documentation and in each part of the documentation is targeting
[09:15] a persona. You have three personas. You have First, the contributor. So the contributor is the person who works on a CI/CD project. So they have a page with what they need to install before, with a video. Then they have another page telling them what to do when they want to start to work, what they need to do when they need to commit their changes, when they need to make a pull request or merge request. And we we create more and more video tutorials because documentation is nice, but nobody likes to read it. But when you when you make a complete documentation with a five minutes five minutes video, people take the five minutes to to look at the video, and they can self train on the tool. But what is really important is to know that on each CI/CD project, you need someone that will take the role of release manager. Without a release manager, it won't work. And the release manager, it is usually a developer, but not mandatory. I know some admins in Cloud IT that can be release managers, and these are the people who know more than the others about DevOps, SFDX, RDS, deployment issues, and they will help their team anytime they will have an issue. Hmm. Sounds like a scrum master in the team to tell people how to do stuff, the best practices. If if we were talking about Agile, yes, it could be that. Okay, and
[10:46] I would assume this release manager at some point he would handpick the features from the contributors' feature branch or commits. We like to to give autonomy to to the contributors. So the release manager. It depends of the size of your project. You can allow you can allow contributors to let's say validate themselves their pull request and if the controlling jobs are okay, or you can you can you can define a peer review or release manager review. It depends because. You have to see SF DX RDS CI CD pipeline as something flexible. You you have let's say a standard CI CD and rules which is opinionated based on our experience, but you can you can change. For example, you can decide that CRM Analytics metadata. You don't deliver them with with CI/CD, but manually. For some reasons, you the release manager can decide which which rules to break and why. Usually, for the the better good. Hmm, and I also understand that there is another role called Setup Manager. Yes, the Setup Manager. It is the person who. Setups the SFDC XRD CI/CD pipeline, so it can be on an existing project. So you have all these steps for
[12:16] the setup are also described in the documentation. So you will start from your production org. You will get all relevant metadata. You will create preprod integration UAT sandboxes. You will configure the CI server authentication between deployment users and and the orgs where you want to deploy. So. But the setup you can you can do a simple setup or an extended one. If you do a simple setup, it can take. I have my my colleague Angelique who is an admin. She takes two hours to to set up a Salesforce RDS on an existing project. But when you do that in two hours, you start with no metadata. In your repository, and it is incremental. Every time someone will update or create something, it will be added to the repository. But I I don't like this way too much. But when you don't have budget or charge, it allows any project to quickly switch to CI/CD. And if you have a little bit more time, you can make a full initialization, a full setup by retrieving metadata and have a first state that you have to to build manually. But again, it is it is described. And once the setup manager finished his job or her job. He or she can disappear from the project. The release manager will handle, and it's okay. But there are some general challenges in Salesforce just across the org and the the Git repository.
[13:46] So, for example. I still don't know. Hardest was a source. How how do we call it? The org based or is it the source code based? Van der Retro source based. Source based. Okay. All the plugins you see, like Kixascale from Aslam or Cumulus CI or SFDX Service, it's all source based. So that means if somebody changes the metadata files in Org, what would happen if they manually change things? You have you have in a SOQL Trailhead Dreamforce AppExchange Nicolas Vuillamy. And you have a simple menu, and basically, when you want to to save, to prepare, to publish what you changed in the org, you have a button where where you will click, saying "Bring back my updates locally in my files, in my Visual Studio code," and then you select what you want to commit. And you have another button that I called Save, to simplify, and and this button will run automatically some scripts. For example, it can you know that on profiles in two years I think Salesforce will deprecate the rights on object and fields. Some admins they continue to put rights on the fields, and if you let that, it means that in three years you will have to migrate to boring. So with a Salesforce RDS, we anticipate that. And if there
[15:17] is some object or custom fields rights defined on the profile, we just remove them from the XML. So you also for SFDXRDs will also clean your metadata and make them more close to best practice. That if you did Salesforce DX manually, see. So just to step back, what you just mentioned is that we are deprecating the profile and use the permission set, right? That's what you need. And in case the user add something into the profile, you would take it back and put it into the permission set. I won't move it to the permission set. I will just remove it from the profile. Okay. Basically, you pro prohibit it. It happening basically in the profiles. Okay. Okay. Yes, that that's definitely one of the challenges to to manage the profiles across environments. So it's a source code based, and you have the Visual Studio Code plugin that basically is to supports admin level who touches the code in the UI. Yes, it is. You have you have simple menus for admins. And for nerds like me and maybe you, you have more advanced menus when you can do more stuff. Even not, in fact, not CI/CD stuff. You can, for example, export all the all the files stored in Salesforce around opportunities for the last year, for example. You have commands like that. You you have commands to you know when you refresh
[16:47] a sandbox, all the emails are with invalid. And so we have we have a little menu that will allow in three clicks to remove the invalid for everyone with admin profiles or even the users that you select. Basically, I work with a lot of admins and developers, and when I see them doing a boring and repetitive task. I say, maybe we can do something for you to simplify your work. So we also have, for example, a command to remove old flow versions. Because when you reach 50, you cannot create more, and you have to delete one by one in the UI, and it's boring. And so we have, we also have little commands to to simplify the work of everyone, and we want everyone to ask for new commands to to tell how this is boring to do that that that that, and we can try to to automate it. So that's featuring hardest. You kind of combine these little features, even though they are not related. They are just some boring, repetitive tasks that people are doing. You think it should be automated, then you added them. So, you must have like a secret list of those commands, or how do I know what what things I can find? Like everything, it is all in the documentation, and you just type sfdxrd in Google, and you you will see all of them. And also, when we have a command, because
[18:17] we're open source, if you want it to work, you have to communicate about it. And I'm not a communication person. Usually, I prefer to code. But like I do today, I force a little bit myself to do more communications because because it helps spreading the open source usage. And and so, so we we write sometimes some articles on Medium, on Cloudity blog. So some videos also. I do a lot of posts on LinkedIn. So we we try to to tell people to tell Trailblazer about. What's existing? What's new? What's to come? So we try to make a lot of communication about it. So you mentioned that Hardy has the Visual Studio Code extension. It also has the SF DX plugin extension. Right. Yes, it is. It is a bundle. You you have the command line plugin and you have the Visual Studio Code extension, and the both communicate together. For example, when the command line ask questions, in the first version, the questions were were in the terminal and you use the arrow up, down, blah blah blah. But my admin colleagues, especially my good friend Michael, if you see me, Michael, hello. They they said, "Go to hell with your command lines. We don't want to use command lines." So I said. Okay, I see what I can do, and so I created a menu that calls command lines, and this is basically the Visual Studio Code extension. And when there is questions inside the command lines, they are sent to Visual Studio
[19:47] Code extension, and so we use the Visual Studio Code prompt interface to to ask the questions, the select to display stuff. So so it's a simple UI, but but basically you see command lines, but You never have to interact with it. You click on a menu to run to launch it. It does stuff in the background, and when there is a choice to make, you look in your Visual Studio Code, and there is a pop-up question, and you just click or write to to answer it. Hmm. But this also comes up another question. Usually, when we use gates, we we use the feature to track who modified something, right? That's a really important feature. But if in this way, does the admins use the UI? Use like a general service account? No, no, no. They all have their own Git accounts, especially to do what you told, to have a history of versions on all metadata, so you know why someone did what, when, who validated, etc. So, we we use the full power of Git to to finally. Have a little idea about what's happening in our project. Contrary to before, with change sets or whatever, it's it's a great addition. Yeah, I ask this question because I have used some other third-party proprietary tools. They use some general service account to move the commits from one branch to another and deploy
[21:17] to the org. And in the end, I don't know was it the configuration was was incorrect or was it the tool? It depends also because I know it's it's not a big secret, but some third party vendors you are supposed to sell one license by user, but some third party vendors tolerate the sharing of users. Okay, because by doing that, when I check the history and get it, basically all flooded by the same service account, right? It's nonsense. Yeah, you don't know what's happened. Okay, so since we have touched on other tools about Salesforce DevOps, I also in the past two episodes I talked with DX at Salesforce Slam and Ramsey. They are doing different projects as well, so we also have the third-party tools. has been many years in the ecosystems. And we also have the Salesforce DevOps Center coming up, etc., etc. I know it's a bit baby face at the moment. I can, I have to remember what how I described it at Dreamforce. The DevOps Center. It's like every new great, amazing feature in Salesforce. When it's just released, it's not great and amazing. It comes with time. And so, for the moment, we tried internally because when the when the wheel is already existing, we don't want to create another one and maintain it. So we we tried it, but
[22:47] first it works just with GitHub, and internally we have GitLab. So it's a it's a bad start. It was too complicated for for doing less than what SFDX does, or Data Scale, or Cumulus CI can do today. So I think maybe in two or three years. Maybe the DevOps Center will be awesome, and at this at this time, I will say, "Okay, guys, let's stop SF DXRDS for DevOps because we have something standard. So when there is something standard, let's use it." But for now, we I think we are still a little bit far away from that. Talking about the tools you mentioned, why the hardest was created because you have multiple projects, multiple scripts, different versions of the same things. It's really hard to manage. But there is something that should not be really part of the DevOps pipeline. For example, translations. Is there really a necessity to really add the translation through the pipeline? It depends because because if if you are in a multi country project, and during the the user acceptance phase, every country will validate that the translations are good. You cannot do them directly in production. You have to do them somewhere else. And once you have done something, instead of manually exporting, importing in each org, maybe you prefer to have it in in your Git
[24:17] and deployed automatically. But again, it's it is a decision that has to be taken by the release manager, by weighing the pros, the cons, and by choosing the less complicated solution. You can also—it is something I like about SF DXRDs. You can also define which metadatas you will never overwrite. So I can give you an example. It could be translation, for example. If you have you have a file where you can configure the list of metadatas to not override, and you can say, for example, if my translation exists in the target org, for example, the production, do not overwrite. Else, deploy it. So it means that the first time you will deploy, and then the metadata will be maintained directly in production because the CI/CD will never overwrite it. It is the same for reports, for example, because you build some reports for your clients, and you they arrive in production. But it is normal that your client wants to add a column or whatever. You cannot ask a client to to create a giant ticket and wait for the next delivery to add a column on a report. So so you can you can secureize what you can what can be overwritten and what cannot. But for this feature, would it fail the deployment? No, no, no. Basically, when you see something that you have to not overwrite, you just remove it from the list
[25:48] of metadata that you want to deploy. They stay in the repository, but we we dynamically create a package XML. That is used for deployment, and and to do that we mix. There is a command that builds the whole package XML of an org from an org, and with this one, we compare with ours. We compare with the list of stuff that we do not have, we cannot overwrite. And at the end, it gives us a package XML that contains only the elements that we want to deploy, minus the the ones we don't want to overwrite. So it will magically calculate, compare the two, or find the delta and prepare the package for you. We don't deploy the delta. It is something that we are working on, but we prefer to deploy everything because. It teaches admins not to update directly in pre-production or production because the first time they do it, next deployment it is overwritten layout, so they are unhappy. But we say it's like that. I told you that you cannot do that here. It is the principles to have a source of truth in in code and not in ORS. But what if the repo is really huge, with hundreds of thousands of Apex, a lot of other things? When we do this, you wait. Okay, I was with. It is the safest way because because and and also every time
[27:18] you make a deployment with a Save DXRDS, you run all the local test classes. You don't select. The ones you want to run, because you cannot know for sure that your update will not impact something very far away. So, by default, when you simulate a deployment and when you process it, you you run and. Indeed, on huge orgs, I have I have a big client, and there are four different Salesforce partners working on the same with the same production org as target, and the org is maybe eight years old. So a merge request control job can take one hour, but it is the price for for safety, for stability, and and to keep your production with too much mess. But is this approach common in other tools like the third-party tools I've used in the past? They always calculate the delta. It depends, and the deploying in delta or specifying the the test classes. These are topics that are. Highly discussed on the Salesforce Salesforce DX. By default, we deploy the version because we consider we have a version we deploy it. But you can talk with with Pablo Gonzalez. He's a friend, but sometimes we disagree, or with other peoples. It's a debate because there are the ones like me who say safety first. And there are others who says, "Okay, but what about performances?" And
[28:49] there are pros and cons for each each side. And but anyway, in a few weeks, it is a request of one of my clients. It will be possible to select if you want to deploy everything or in delta. It will be just a configuration variable in the Salesforce RDS. So, even if I disagree with such with such actions, the delta deployments, especially in production, I don't want. My own opinion to prevent someone from using a SFDXRD, so it is for me not the best choice. But I prefer someone using a SFDXRD with delta because I allowed it with an option than someone saying no. If SFDXRD doesn't do delta, I won't use it. See, I try to adapt what the tooling can do. You can diverge, right? Yeah, we have the second generation packaging already in Salesforce for a couple of years. That's hardest to support, like split things into multiple repo. No, if if you want if you want to do that, I think Aslam already told you. But to do that with open source. This is the exact scale. SF DXRDs can be used to create one managed package. So if you are change editor, because Cloud DTE, we we are editor for several companies of their Apex change solution. So you can use SF DXRDs for one package, but alls having 50 packages deployed in orgs, etc. DXA scale already does that very
[30:19] well. Maybe cumulative CI too, no less cumulative CI. So. There were already wheels for that, and but it it was too complicated for our population where there is a lot of admins. So. So I think it is a cleaner way to do DevOps to use DXA scale because you have modular stuff, etc. But It is much more complicated to explain to everyone to onboard admins, in my opinion. That's why SFDXRD addresses it is more mainstream SFDXRD because anyone can install it, can use it, but you cannot do modular advanced stuff like DX scale. Before we end, do you have anything else you want to share with our listeners? Well, first, thanks to you for your invitation. No worries. Thanks to all the Trailblazer community, using what we do and contributing more and more. And like I always says, when you want something and when you when you are angry about something, it's in the Salesforce RDS. Complain and in GitHub issues, so we will see it. So it is by people complaining or asking more stuff that we make the tooling better. So we are nice people. Don't hesitate to to ask for stuff, to complain, to communicate and. And it will make this Trailblazer Community project even even more capable. Thank you, Nicolas. See you next time. Take care. Bye bye.
