Azlam Abdulsalam, who joins to talk about The Ops in Salesforce DevOps, is A DevOps expert and OpenSource Project Flxbl main contributor.
Main Points
- Developer skills and DevOps
- What problem DX@Scale attempts to solve
- Make a clear boundary between Dev and Ops
- How Scratch Org helps with the boundary and dependency challenges
- Review the DevOps problem in Salesforce
- Big complex Salesforce v.s. Small and medium environments
- The penalty of maintaining a poorly maintained Salesforce environment
- DX@Scale and sfpowerscripts
- The mindset of creating tools and helping others
- DX@Scale roadmap
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:09] Hey 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 is Azlam Abdul Salam. Hello, Azlam. Hey, hello everyone. Thanks for the invitation. It's been a pleasure to be featured on Salesforce Way. I have been working in the Salesforce space for the last five years. Before that, I had you know multiple opportunities work across the tech spectrum. So I started my background as a software engineer. You know. As would always been with computers from my younger years, started my career professional engineering from a mobile gaming perspective. I worked on some cool gaming studios such as Game Loft, and you know into casino gamings and all into mobile applications. Then moved into the enterprise application development, you know with AWS and Azure and the likes of the cloud. And then subsequently, I moved into Accenture, focused on DevOps tooling and technologies, and that's how I came into with Salesforce, and I've been into the Salesforce space from there on. I see that you are working together with Ramsey on a project. Am I right? Yeah. So I've been working with Ramsey, you know, in Accenture, and then subsequently from an open source perspective. So I used to work with Ramsey on the you know projects in Accenture.
[01:40] You know, and where I used to mainly focus on the platform engineering or the tooling side, where you know he used to focus more on the architectural delivery side of stuff. I I still collaborate with them to this day, from an open source community perspective. Though we are different firms at this point, and you know we work together to understand and you know build a common idea and shared understanding of these tools. Last time he was on this show, the previous episode, he shared a idea that he thinks in Salesforce there is no DevOps issue. Are you totally agree with him? I think you know you need to look at with a different lens to it, and I think. He's fairly correct, right? So, my point of view around that she is, you know, before we say there is no DevOps problem, I had struggled when I came into this platform to understand what is development and ops in the context of Salesforce. I've been always been confused, so I used to go and ask around Salesforce CTEs, and I've been very fortunate, right? So I've been working in Accenture on large scale projects. You you get to ask to a lot of people around that. I used to go and ask them like, hey, because I used to come from you know the cloud background, and I came into Salesforce project. I quietly didn't understand, right? So hey, here Salesforce, which is a SaaS application, the operation side of the platform is handled by Salesforce, right? So what does an ops
[03:10] engineer do? You know you don't check your disk space. You know you don't. You know you you have one click button to spin up a sandbox. Awesome, pretty awesome, isn't that? Because probably if you go to a cuban at this project, you know if I am a platform engineer, I would spend the next three to four months writing scripts. To you know, to give you that one-line command for my development team to spin up a developer environment, you got the CLI which has a push and pull. And and you're like, oh my goodness, you got packages, SFDX package create. Oh, you create a package, SFDX package version it's public. This is awesome, right? Yeah, and then I went and created these pipelines. I remember, I think within you know two three weeks, I read the documentation because I had to do other projects as well on the parallel. I was looking into a Drupal instance for that particular organization. So Salesforce was just like on the side, right? So I'll just keep reading it. I'll just build the pipelines. I'll build the workflows, and I will move over, right? So that was the whole idea. So I was reading it. Oh, it's pretty simple, right? It's even simpler than the Drupal instance I'm playing with. You know, you just need to swing up these commands and hook it up, just deploy it, and you know, just set it up and move on, and. I remember I going into my peers the next you know after two to three weeks and once I set it up everything is looking fine. I can spin up an environment. I I never knew what the Salesforce is, or I never understood
[04:40] the lingo. Right for me, it's just a business application at that point in time where I'm supposed to build a pipeline and operate it. Fine, fair enough. I had a team to work with, so I my assumption is the engineers and developers that sitting in front of me they don't get. There are engineers and I my. Talking point to them as I'm just drawing a Git Flow branching model on the board, and I'm like, "Hey, from tomorrow, you know, I have I I looked at the documentation. Looks like Git Flow works for you, so you should start Git Flow." And Salesforce has just introduced a brand new package management, which is amazing. So you guys should use package management, you know. And because we get a free artifact repository out of it, we don't need any infrastructure cost for it. And it's and you should use Scratch so successful, right? Because there's an empty org in front of you, and we can deploy it. And it's a brand new project, see, right? It's it's a green field project. So I'm like, yeah. What else do you want? And everybody notes to me, like, you know. I'm like, oh, this is fantastic, right? Because the people understood me, and I'm like, great, this is a amazing opportunity. And I'm like, oh, Salesforce is done. It was the most simplest stuff, so I'll just go and focus on the remaining tech stack. I come to my desk, you know, sit there, and then I get my peers coming, and I'm like, hey, how do I use this terminal to create scratch chocks? Then
[06:11] I'm like, oh, you could type over there. I just can't can't identify which folder should I navigate. Then I'm oh, what's happening?
[06:25] So maybe then it's one person. So but then I could see similar comments coming in, right? Hey, you know, you need help. We need to navigate in the shell. Then I'm like, okay, something is off. Maybe you know my understanding is wrong. So I quickly had one of my colleagues who I've been interacting with to understand Salesforce. I'm like. What is happening, right? Why are you guys finding it tricky to use VS Code and terminals and all this stuff? Oh, hey, we never used it. This is the first time you're going to use it. Oh, that's when I'm like, all right. So this is a completely different ball game. I used to nag my colleague money every then and now. Hey, what the heck is a profile, right? What is happening? Because folks used to come and tell me, hey, your pipeline is not working. Then I I log into Azure DevOps at that point in time. Look at the logs, and it says something is not deployable, right? And the error is valid, so I went and tell them like, Hey, this is a valid error, right? Something you built. In your code base, it's not getting deployed into it. There is nothing wrong with the pipeline. The pipeline is just printing what is exactly what Salesforce is giving you. So I would ask you to go and fix it, and they would be like, "No, we did the same thing on Developer Sandboxes. It's working, but it's not working on this environment." I'm like. Yeah, so I would, I, I would
[07:55] then I would go to money and like, hey, money, what is happening? Can you explain to me, like, how does this thing work? Then he had some explanations around, hey, this is what profiles is, and it carries every objects which we haven't touched, right? And that was like, okay, so I think that's when I started looking at into a very different model, and I was like, okay, for me when I am looking at Salesforce, it's more of transferring a desired state of configuration. So you are working on a sandbox. You are applying a state onto that environment, and then what you are intending is you want the same state apply to the next environment. So the word deploy is inaccurate, to be honest, right? It's more of like apply. I need the state of the sandbox to be applied to production. That's what basically you're doing. So with that understanding, then I had this opportunity to build a set of scripts. Right, and it was mainly that when I look at it, it was again focused on the development aspects. Right, you are basically transferring your scripts or you are transforming your XML on the fly and applying to the next environment, like removing user details or removing environment specific details. From those XML, which should not be there in the next org, because you either accidentally added a test user, or you added some aspects which should not be the next environment, right? So you're basically cleansing your XML
[09:25] and making it ready so that the state is applied. So then, and when you start combining all those things, right? So that's where scratch orgs become phenomenally good, is that you get fast feedback. Like you get to know that hey, this state will fail in the next environment. Right, because you can validate that in an empty environment. See that these configurations are not normal. These configurations are only work when you have an associated data with it, or when you have these uses set up. Right, so you know, just more relating to it. So then I all then even with all those things I was learning, and then I I still come back to that question. She right, what is ops in all of these? You know, so I used to go around and ask. Like, so I think that's where, from an ecosystem perspective, the term admin is very over conflated. Right, because admins also do development. They also do kind of operations on the platform. Right, adding a user to a queue. So there are a lot of activities that they do, which is basically they using the platform. Right, and then we are combining those activities into a DevOps pipeline, where you know we are asking all the DevOps processes. Right, we have shifting everything towards the left. And we are saying, okay, hey, we will use version control to deploy, and and and and you know deploy that to production, but. You see the issue
[10:56] there, right? On one end, I am supposed to use the system. I am supposed to go to production. I am supposed to do an operational activity. Right. At the same time, we are asking them, "Hey, oh, you should not touch production. Uh, you should do everything from version control perspective." Right, and then you should flow that across five or six environments later onto production. Right, so there is a you know there's a conflict between those, and and the kind of notion in the community that hey main branch represents production, this branch represents this environment, this represents the state of environment, and then you get tooling trying to do all those kind of stuff. Right, that's when. I met Rumsy, and we were discussing, you know, the troubles with packaging and projects because projects were not understanding it. And he was like, "Maybe we need to take it in a very different kind of model, right? So maybe we need to think that packages and all those aspects represent development." Right, and then you can have right. They represent the architecture of the system. They represent what you need to be developed, rather than what does need to be operated on. Right, and then you get your other configurations and stuff, which is basically you are configuring on top of it. Right, and how do we identify those boundaries? So that thinking, and from that angle, we started more on the concept of DXS scale and those kind of terminologies around that. Just to make
[12:26] sure I understand, in Salesforce it's always a bit struggling. When we want to deploy things into the next environment, we always have this low code the configurations, which is represented as XML files, and also we have the real code, which is Lightning Web Component Apex. So, I still don't know today. Should we split them, have a clear boundary to deploy the two things separately, or do we bundle them together? Which is is struggling. I, for in my view, I think it's it's not about the separation of those aspects. It's the separation of the operational aspects in it, right? So, for example, when I if you want to do a development, right? See, and then you are being asked to create an automation which pushes you know some emails to a group of people in a queue, for instance, right? So this could itself be a development story, right? But adding uses into the queue is an operational element. Right, so I could have a public group as part of my development story, and then I could write a flow or an Apex code based on certain conditions that it drops a message into, you know, into the queue and into the members for the members of the queue. That aspect could be packaged, or that could be you know grouped together and could be deployed from left to right, right? But then there is an aspect of assigning
[13:56] a uses to the queue. Where does that belong? Why does it have to be on your left? Right, because you don't even know who the end users are at this point in time when you are developing the story, right? And you you might add or delete users. Right, when we are trying to make sure that all those environments are trying to be in sync, right, that's when all the problems originate, right? Isn't it? Because you you are ensuring that every users in production is there in every other environment. You are trying to build the queue. You are assigning the queue on your left. And then you are make basically pushing that configuration across your all these environments, right? And this aspect doesn't scale when you are on a larger team. So imagine this will work. If it would have worked, if it was a one-to-one mapping, right? I go to sandbox today. You know, I just want to work on a feature. I spin up an environment. It has everything as in production. I can quickly test it, create, then I can deploy it back, right? But when I start scaling it, when I have three or four teams running parallelly with each other, they're building complex features. This thing doesn't break because there's a whole lot of time gap between the feature that is developed reaching the production. So the environments try to get out of sync pretty fast. The tools and ecosystem are trying to do is trying to get all these environments in sync, right? Either using backward
[15:26] and forward promotions and or using branch merges. We are trying all those kind of techniques to make it in sync, right? But can we look at bit differently? Can we look at and say, hey, what is a functional element of it? Right. Okay. I need a queue. I need the code and logic to put something into the queue. Right. That's what I'm supposed to be developing. I could assign users that could be an operation element, right? Which could be as I assign to an ops engineer or an admin. Hey, once this feature is deployed, assign a set of users, right? And these users are available only in production. Fair enough, right? And that is where we, when we try to understand with that angle, that's when you see scratchchokes and things become really effective, because this scratchchok doesn't have any know how of your production. Because scratchchoks will start warning you, hey, this user is not created. This user is not available. So suddenly you are like, ah, right, right. I I should not do that. This thing will not work, right? So suddenly I am isolating, I am cleansing those metadata of those things and making it work. So that's what exactly what packaging does. So when you use the default normal Salesforce unlock package, right? So Salesforce cleanses these metadata off from those packages. Thus ensuring that core functionality is able to be deployed onto any environments, right, and then you could have the operational elements on top of it. Oh, I need to assign few
[16:56] users. Please feel free to right because you are just using the system, you're assigning it. So that was that's one way to look into it, and then. Suddenly, you can see your version control is very accurate to your development, right? And you know it's very easy to sync your environments because you have already identified what are those entities that can stay out of version control, or it could be recorded in another version control, or even in other systems, right? Because these are not these are systems that are dynamic in nature. These are something which happens in production, right? Which you doesn't have to be in your version control because these are not your core aspects. Uh huh. So does it mean in the traditional way of using the sandbox for the development? Because the configurations, the users are already in the sandbox. So accidentally, you may not see something. Has a clear boundary between the operational. Exactly. So, yeah, correct. So, I was working on a very recent project of mine, and then we had a very interesting scenario over there. The test classes fail on certain environments, okay, while it works on certain environments. What is happening? It was tied into certain specific uses, and in some time, that you know, we disabled those uses. So when you run all the local tests in that particular environment, this was happening right because the environments were not refreshed consistently. It was like you know we can't right because there was integrations tied into those
[18:26] environments. It's been so whenever if you want to refresh it, you want to recreate all those integrations with different third party systems. So you know it was left there right. So deployments were happening, but when we try to run all the tests, we are not getting right signals, right? Because tests were always failing, so nobody was like, "Okay, hey, this environment test will always fail, so ignore it, push on," right? But I'm like, "Why?" Let's have a look into it. We looked into it. Ah, these uses were disabled, right? And then the uses were embedded in the test classes. So the one of the things that we did, I did was that oh, whenever you're creating a developer sandbox, I just disabled all the users, and I created a dummy user. So they change the behavior of the developers because developers now can't assume a user exists, and you are always provided a dummy user, so you can't write your test class with that because the dummy user will not be available in the next environment, right? So then people started using runners with right with profiles, and the behavior slowly changed because you are being you're getting feedback immediately that this thing doesn't work on the next environment. Right, so that is where the issue with sandbox based development predominantly is. Right, sandboxes are test environment. It's not a development environment. Right, so you are basically carrying all the configuration of your production environment, sands the data depending upon what what type of sandbox is on to the left. Right, this was one of the biggest learning that we had in the first project. So even though we struggled
[19:57] a lot in you know when we went to scratch org that was just launched, the features was not there. So you know we we burned a lot right. So we were literally struggling to get those infrastructure working because each time we need to understand a feature to be turned on, we have to go through the scratch org definition, try a lander, and get it working. But when it comes to deployment to production, or when we want to sync an environment, it was super simple. Because our version control was pretty accurate. Sands the operational elements of it. We can always spin up an environment. We are pretty hopeful you can deploy this, right? Because we exactly know the order of the metadata, and you know it was like very clean, as in because we have been validating across scratchlogs and all this stuff, right? So that is what predominantly what our thought process, you know, across when I've been working across these projects are, right? So how do we get? Fast validation to the developers that something operational has got into your your code, right? And also the boundary tree, right? How do I know that I'm not sidestepping somewhere else and I'm creating a circular dependency, right? Because again. The projects that I work on are predominantly huge, so we have multiple teams operating, right? So how do I know that I haven't accidentally created a dependency on another team's feature, and and the other team says, "Hey, I'm not ready," so suddenly I am in a puddle,
[21:27] right? I can't deploy anything without the other team, or you know, somehow merging and going together. So these are the situations where. The tooling or the system should actually provide feedback. Hey, something is going to go off, so that that can trigger a conversation. Right then, I can come to you and say, "She, I want this thing, but you know, unless you deploy it first, I can't have it. So, you know, what should I do about it?" She coming back to your first question: Do we have a DevOps team? Yes, we do. Let's begin by classifying what the problems are. Right. So we we we talk about. DevOps as such, we just talk about deployment, but I think there is more to it. You know, it's not just about deployment. It's predominantly about environment management. It's about how multiple teams operate together. It's about even life cycle of things. Right? How do I even deprecate a particular feature once it has reached the shelf life? Once a business decides we don't want to use the feature anymore, right? What is that story? How do you do that? How do you handle your integrations? How do you do mocking? So there is, it's a very wide area and. What I see in the industry is always it's all tied into hey I just need a cool UI to pick the components that I picked up and deploy that to the next environment right. Everybody comes and solves that problem again and again. I'm like, we we need to move on from there right. We have much better problems to solve and so.
[22:58] Yeah, I understand what you mentioned, and I try to also advocate this of professional thinking, because the software industry has been so many years. There are a lot of things to be covered on a professional level. If you're just doing it as a hobby, one man project, yeah, deployment maybe that's the only thing you need to think. But now we have the teams. Covered right? How to fix the conflicts? How to roll back the feature if you see something bad happens? Right. So all these things should be in a fast manner and in a professional manner. So those things has been in the software industry so many years. We definitely need to bother that. And you know, recently I had a chat with one of my good friends. Let's say he is a manager in a company, a Salesforce consulting company. I talked to him about this modularization thing, right? We have it so many years already. So let's use that. But he gave me a comment that I don't even know how to reply. He said we still have this traditional way of, you know, sending the things across the sandbox. It works. Why should we think about the new way? The old way works. Why do we do the new way? There's no hurry to do that. I was like, no. I think I think he's spot on, right? So you know, once I started working on the exit scale and building the tooling, right, I would see always this pushbacks when we go to customers and we tell
[24:28] them, hey, we, you know, it's it's not a DevOps problem, Fox. It's it's more of an environment management problem, right? So it's about how do I handle. Environments at scale, right? How do I handle your UAT, your SIT, your developer environments? How do we keep them all in sync? So we need to look at a different lens. We need to make sure that every piece of metadata is deployable, consistently, repeatably, right? And you know all those kind of jazz around it. So I keep on telling them they're like, okay. But to do it work, you need to think about small pieces, small modules, right? And then we need to do that. And they're like, oh, that's super hard, right? Because once you're clicking in a UI, you generate something out, and now you need to understand the metadata API. When I look at my practices and the projects that I'm working on, suddenly Salesforce is the center of that ecosystem, right? So you have ender CRM data, you have ender your, even your financial data in some cases like ERP using financial fours, health cloud. I mean, the amount of money that's being spent into the platform, and the amount of money that it generates—it's huge. And are we? So are we saying that you don't need any sane practices that should be applied to the ecosystem, right? So I would rather look at and say, oh, this is too complex, right? I should get the best in tooling out there, right? Rather than looking at, oh, I just need to continue what the traditional way of doing it. No, that is fine
[25:59] if it's small. If you are doing it for the traditional way Salesforce was supposed to be used, like if it was just small changes that need to be applied, but right now I'm having a bank running on Salesforce, so I need the same rigor. I need to bring in traceability. I know I have auditors coming and auditing Salesforce. I need the same security restrictions on it, right? So things have changed, right? It's it's more as a looked as a platform rather than a CRM. Or a you know a SaaS solution that can be bought from a credit card. It's not right. It's it's a it's a very complex platform you are using as your backbone of your enterprise where other systems are going to interact with it, and then it's time to apply a critical thinking to it. Right? How do I maintain this? And and I think we should borrow other practices from other ecosystems to maintain it. Yeah, this is a really good point. Last time, Ramzi also mentioned this. If you are using Salesforce as a really a low code platform, you're just building some reports, some out of box automations. Then just use it as it is. But if you are having it as a strategic CRM system in the center of your company, there are so many integrations around it, and so many teams building the new features as the customizations. You have to apply the modern software. Yeah, absolutely, right. Because because the amount of changes that's going on is pretty huge. The amount
[27:29] of features that is being serviced by the platform is huge, right? You are sending emails out, right? So mistakes or this can be really critical. All right, you could be sending mass emails to you know hundreds of users out there, you know, with an incorrect messaging. You are calculating loan payments on Salesforce, right? So these these are highly critical systems. So we need to ensure that the change is properly validated, it's accurate, and we also have have a mechanism to sunset it, right? And as we grow along this platform. The amount of configuration is growing tremendously. You know, when I onboard a new developer, he has to come in. He can't just see a single repository of every component in the world. I need some kind of logical separation of ideas, right? Hey, which team do I belong? What do I own, right? So traditionally, you know, people would use prefix with the namespace. And when I was talking about our friends today, he was like, okay, hey, we have a Confluence wiki which details every component that is owned by each team. Right, and I'm like, what a waste, right? Like you're, you know, you're you're building an enterprise system. You are basically replicating thrice, right? You got a you know a workboard tracker like Jira or you know Azure DevOps board where you have
[28:59] a work item being tracked. Then you got a system like Confluence where you're basically saying Apex class one belongs to team A. What does it use for? And then you got a version control system which has exactly the same replica of whatever is mentioned. And then over there you are again commenting out. Hey, this Apex class belongs to there. And then me as a new developer who is joining it, I am looking at three disparate system trying to understand where I belong to and which components should I touch to. Right, and so this is this is massive loss of time here. Like whenever I make a change, I need to touch three systems. Let three systems, you know, know it. Right? Hey, I need to update conference document. Hey, this ten fields belongs to this team or this area of the business. I made X number of changes in that class, so I'm going to write a header, one, two, three, four, five. These are the changes that is being applied. I'm like, hey, isn't that what version control system does? Why does your architectural documents doesn't resemble the state of information in your version control? It is as simple as just creating a folder and moving things around, so that your PowerPoint presentation looks exactly similar to what your version control does, right? Is isn't that the fidelity that we want, right? So right now we are trying to reconcile three systems. What if I forget to update Confluence? Suddenly you have an orphaned entity. Right, so I
[30:29] I think that's where the thing is, right? So we are we are not worried about those costs. We are just worried about the current costs. Rather, we are not seeing the amount of time a developer comes in, spends in, you know, to understand where this, you know, how to make these changes are. So she, when I, you know, when I I had this unique opportunity to work at cross projects, and one of the things that I learned was once. You are into Salesforce, three four years into the cycle. If you have not done thus, you know set up properly from you know the way to architecture properly. Suddenly things become to a crawl. So you know you you have a sprint of two to three weeks. Suddenly the number of work items that's coming out is like very slow because the business doesn't trust us anymore. So they are like, okay, hey, you know, what are changes that you make? I will spend the next one week testing it before I approve to production. So that is roughly the state of affairs in in large enterprise setting, right? So even though the changes are coming and things are slow because you know we have a lot of things have been burned, so people come in. Hey, I need to do a UAT. I need to do a full regression. I need to run all this UI testing. So suddenly, the and and we have customers who come and said, "Hey, we are not, you know, we are not getting the value out of this platform." That is the messaging that I want to leave you with. See, right. So when you hear that, I think what we need to discuss is, hey, is Salesforce your strategic platform? Are you going to continue investing into it? If yes, I think it's time you look
[31:59] at additional cost parameters to see what is going to happen in the next six to one year, right? How is your cost of onboarding? As how is the cost of a change would be, right? And how fast you can deliver stuff. So, so with with those parameters, I think you can get a better idea, you know, whether you should invest into those aspects. Azlam, I really enjoy what you just mentioned. Salesforce usually it's a long term platform in the company because it's customer data, so it tend to live long. And after five to ten years, the platform has a lot of features. Onboarding a new developer might take a lot of effort, a lot of time for him to understand. Okay, what the dev team is doing, how maybe he touch one thing would break so many other aspects. All those technical debt is in the platform. It's just not easy anymore, and the team might not know why it's getting to this situation. Or sometimes, team might find the argument say it's because the business is complex already. the The company is growing, right? There was a business is complex, so it has to take this much time. You know, there's like kind of a conflict between the dev team and the business, so mutually they just don't trust each other anymore. And I've seen this happening, you know. I've seen this happening as well. Yeah, I completely agree with you, Xi. Right. So I think that's what's happening as I think that's where.
[33:30] We developers have to take a bit more control, you know, on the way the systems are architected. Understand, you know, the inefficiencies in the processes, and then you know, we determine the course of action, right? So, you know, how does it look like, and how does it work, and how do I make my own life easier, right? So, I think that's the concept we need to apply, right? So, you know. When you are developing, you need to think. Hey, can can this be quicker, right? I don't want to repeat this same process every day in and out. Something is off, right? So can I make it easier? Can I make it automated? I think that's that's once you cultivate that kind of thinking, suddenly you see these problems vanish to a bit, right? It becomes more easier to manage.
[34:17] So, you mentioned the project you are working with Ramsey together. Is that so called DX at scale? That's the official name. So, introduce us what what is that project? What do you do there? Right. So. So within the first project that we worked, we found that there was a need of scripts before, you know, doing a deployment or after a deployment, right? You you need to do some transformation. So I was basically collecting these scripts into a reusable component, and that's when I was I discovered, ah, amazingly, that Salesforce DX. You know, that that was an amazing thing about it, right? The team had thought about a lot of angles, and they had this concept of plugin. So you basically can write an SFDX plugin. You can deploy that to an npm registry, and then suddenly you can share it with your other projects, right? So. And I was like, okay, and that was led to the creation of SF Power Kit, which was one of those first plugins. So I, you know, basically looked at how the CLI team was working at their code base. It was it was not fully open at that point in time, but you could still see, you know, what they were doing with the CLI commands, how it was operating. I was like, okay, hey, there are gaps in these areas. Or then I started writing small scripts around it. I had amazing help from the team, like people like Manny, Nathan, Rudolph. They were all helping me. You know, you know, and so helping me to write those scripts, I had once you know met somebody from Mauritius, Genod. He was actually writing a profile reconciler. Which is an amazing tool.
[35:47] Which till to this day, even though SAPOQL is deprecated, lot of people uses it. What this command does is it, you know, it looks into your org, understands all the fields, licenses, user permissions. So suddenly, when you deploy this in your pipeline, you don't have a profile issue anymore. Because you know, if the target org that particular object doesn't exist, no problem. The profiles doesn't go in, right? It just gets cleansed. So, this was a reconcile command. You know. So I, and then I found that that was a needed in many projects. Right, so you know the same thing. So I, you know, that was what came into the origination of Power Kit, right? So Power Kit was basically a collection of you know tools. And luckily, Accenture—you know—I talked to you know Accenture leadership at that time, and they allowed to open source it. Right? Hey, you know, please feel free to open source it. And then we did that. And I think it's still to the day we got, even though it's been deprecated for like one year, it's still downloaded. Right, so there are a lot of commands, right? Like you want to disable an IP range for whatever reasons, you know. You want to split your custom labels. You want to do a diff between two deployments. You know, anything, right? So there are a lot of commands which people contributed over a period of time. And that was my first thing. That was my first understanding of how to write an Apex plugin, and and I believe every developer should look into it, right? Because it makes life lot easier. The Salesforce team has done an amazing job, you know, removing the complexities of authentication handling, etc. So as a plugin developer, you can just focus on what you want to do,
[37:17] right? Then. So while doing that, then I found that there was a need for you know the DevOps tooling. As in, I I was like getting frustrated, right? I built a YAML pipeline in one of those Azure DevOps. Another project wanted similar stuff, right? So they also wanted similar pipelines, right? So that came into the genesis of Power Scripts. Like, hey, can I combine these automation, you know, these if conditions around it and make it distributable? So that next time a project comes in, they can install it. They have basic building blocks available, say authentication, deployment. It's already built in. Can you do that? So then I looked at it. Ah, amazingly, Cumulus CI. Right, they have amazingly done that. Right, so similar piece of functionality. Right, they have. So again, see, it's not about whether you're solving automation. It's about How do I maintain that? How do I keep on updating it? How do I do it across projects, right? Because you can do that from that. That was a beauty of SFDX plugin, right? Once you get into the npm registry, you just do an update, and every one of your consumers get an automatic update. So you get a bug, no issue. Just do it, right? Whereas traditionally, you would otherwise would be sending in a bash script. Hey, here is my bash script to do that. And then you have now two copies, the same old problem, right? Now you know once you convert that into a library, a tool, suddenly you can do an update. It's versioned, and then people found that to be helpful.
[38:48] Into my surprise, right? People found that hey, it's very easy to drag and drop and build these components up, build a pipeline out of it. I am like, okay, great, this this thing looks interesting. So then I started investing more time into it, and then that became a project of itself. You might have seen articles around, hey, setting up data scale is hard, and it's meant for modular. But once you set it up, then you don't have to worry about your pipelines anymore, right? So you know you just keep on doing your Salesforce work, as in create packages and do packages, and and the tooling underneath it will know what exactly what you're trying to do. So over period of time. It became started using my projects again. You know, we made it open source, so a lot of community contributions came, and and then we started looking into those nuances, right? Like for instance, when you do an unlock package, you know, the layout assignments doesn't work, or the field history tracking, you can't do that. Because it's an operation element in the context of Salesforce, so they will not do that aspect. But when you do that for a org based development, or you know, when you are doing for one single org, it's painful, right? You know, if for every time you change a field and you want to add a field history tracking, and you are doing an unlock package based development model, it doesn't work. So you need to go to your production manually enable field history tracking. So it become a very big pain point. I am like, why don't we solve those nuances into the tooling? In a declarative
[40:18] model, right? So the tooling will step in and solve it. So rather than letting the developer, as in with you know with Cumulus CI, which was looking at from a more from procedure angle. Can we provide with smart defaults, and can we provide it with a desired configuration? Right. Hey, this is what you need to do. Don't touch anything on the pipeline. Let it handle it. Right. Let it try to figure out what it needs to be done, and then if you don't, if you don't like it, of course there's a mechanism to turn that off. But again, without touching your pipeline infrastructure, so that is where the exit scale originated. So Azlam, you mentioned a lot of things here. I need to break them down into pieces. You mentioned how you. Change your scripts into a tool that can be shared across multiple teams or like open sourced way. I think that's one thing. Our Salesforce developers are lacking that skill. Is most of us are working in one customer work, but to build a tool which is more common, more abstracted, is a totally different skill level. Many of our developers, we don't have that skill. Let's put it frank, and because of that, once our solution become more complex. We don't have the skill to handle, to abstract them, to touch the code. You know, to to make the code clean and easy to to read. Because of that, we have a lot of technical debt. I've
[41:48] seen that. Yeah, I agree with that. I think at the same time, she right. My my always advice to my juniors is that you know, you know, you you can always have your own personal set of tools, isn't that like you know something that you like a set of. Apex classes or set of framework that you built, right? It doesn't have to be perfect, so you can all, you know, there is always resources, right? So GitHub, you can just create a public open repository on a, just just put it right, and people have this notion that you know suddenly people are going to come and see my bad code. No, there is thousands of repositories. It's simply not reachable. So just just just keep on building it. Just when you find an interesting gist, just just write it down somewhere, right? And then once you have it, when you look back. You have a good trajectory. You can just quickly and see how you as a developer has progressed. You know from from your understanding of the things, right? Because maybe the first repository you created was not a good idea. Maybe the third one is a better idea, and then you can use that to share with your fellow developers. Not. Within the company, right? You could just maybe on you know a group or a trailblazer. See, one of the things that really helped me, she in the Salesforce ecosystem, was the trailblazer community, right? So I started, you know, how the community got really traction was in the Unlock Packaging community, where Andrew Davis from you know he was at Appier at that point in time, and you know there was a lot of people who were interested in Unlock Packaging. So people used to come and ask questions. Hey. What? How do you solve this? And then I'm like, okay,
[43:18] hey, this is how I solved in my project, and here's the gist of a script on how we used it. Then somebody else would come and say, ah, this is how I solved it, and this is how that particular script would look like. Right, and then that facilitation in the community side, in just in Trailblazer community, right. So I think we just need to get rid of that hindrance that somebody would see this thing and it will look feel bad about it. I think that's what we need to avoid, rather than the skills. Okay, what's the future plan for DXS scale? Yeah, I touched upon this a bit. See, so I think you know we joke about it a bit. DXF scale was predominantly designed with a developer person in mind, but we need to take that into the next level. Where how do we get the people on the right who are operating the system is able to use these things easily? And DXF scale being a CLI interface today. You are not able to surface those information, right? So, what is happening when five different teams are building six different packages? Which one is failing? Which one is succeeding? So, you know, all these information are in build logs. So, we want to, you know, extract this out. So, there is a lot of people in the community who is working on. You know, combining JSON outputs from different parallel build jobs, so that we can actually see what is happening and then optimize further on based on that. So
[44:49] it's amazing. So you know, being in the community really helps. We can we can know what is actual pain point from a user perspective, and then react to it. So yeah, so a lot of things coming in the pipeline. So mainly the UI focus towards operators on the right, and and a lot of optimizations on the left. Thanks a lot, Azlam. I'll put the DX at scale information in our show notes, including you have a Slack channel there for the communities who can share feedbacks, give comments there, right? So I'll put those information in the show notes. And good luck for the open source journey. I think you have learned a lot. You enjoyed it, right? And people love it. Amazing. So I I would recommend everyone you know to engage with open source to share what you're building. You know doesn't have to be really be perfect. Just just get on to that and you know even whatever simple is it, even if something has been created, just feel free to share your code bases. Across it, ask your peers for comments on it, and those would really help. So you know, it's it's a it would really help you in your career, right? Yeah. So it's amazing. All right. Thanks, thanks Azlan. Thanks for coming to the show. Hey, thanks, thanks for the opportunity.
