Description
In this session at DevOps Dreamin’, Deema Rahim, Director of Architecture at MTX, explores how to create a solid Salesforce DevOps strategy from scratch to achieve your organization’s goals. Deema covers:
- What a successful DevOps strategy is
- The approach MTX took to build a DevOps strategy
- How to deploy a DevOps strategy
Learn more:
Transcript
Okay. So my name is Fema, and I'm the director of architecture at MTX.
So let me give you a little bit of a background of what MTX is. It's a consulting firm, which we basically deal with the commercial and the state clients. So for us, you know, we have more than hundred projects, and we were working differently. And this is basically before the DevOps strategy.
This is how we were operating for all of those projects.
You know, we had different tools.
We have, different sort of times, some, you know, different release cadences.
So if you really can you hear me fine? Because if I move away, maybe I can have a mic too. It will be easier for me to just walk around, if that is okay.
So if you see that, you know, management was asking, okay, different orgs, you know, gear set and some other tools also, And management was saying, what does the health look like for each of the projects? So it was very difficult to go to each of the project and say, you know, just again, you trust the team, but trusting the team and saying everything is fine, very difficult to report on it, no visibility. Even if the client is asking, you know, what is the speed of delivery? Very difficult.
Manual processes because people were not following the standards. There was no COE, center of excellence. There were, no monitoring, and so tools were there and no quality. You know?
Quality was there. But, again, when you're not monitoring it, you don't know how the quality look like. Maybe on some projects, it was hundred percent. Maybe on some of the projects, it may be eighty percent, fifty percent.
But how do you monitor with all that scalability of the projects? And then if you have to have a new project, then you have to start zero because you don't have that centricity of the knowledge of how you deploy the DevOps. So you have to start from scratch. So that means that every new project would be a new implementation for even DevOps when it should be just operation.
Click and tag, and that's about it.
Also, security risk with, you know, when you talk about DevOps, you're not only talking about one tool of deployment. You're talking about your, repository. You're talking about your scanning of your code and everything needs to plug in together, your communication and collaboration as well.
So that's where someone wanting, some projects or clients wanting speed of delivery, some people wanting automation, either it's QA automation or it's deployment automation.
Then management wants visibility on everything all across.
And then also stability in production, in UAT, because some of the clients thank you so much. Sorry. Can you hear me fine? Alright. So some of the clients would basically have the UAT whenever they go want to do, they go into the environment and they start doing the UAT. For some of the clients, you will have the specific UAT cadences.
So that's where, you cannot hear me?
It's fine?
All right. Okay. I'll speak in this.
All right. So that's where you wanted to have a tool or the set of tools and processes where you can give the client all of that, the agility, the speed of delivery, quality, and, of course, visibility. So this is overall hundred plus project. So what we envision is management.
So a DevOps strategy to combine practices and tools and also the methodology with higher velocity, also the confidence in core core deployments into different environments. So we have that confidence in management that the product will go into UAT, into dev, into production as, you know, it is a it has been tested in every environment.
And, of course, the security, because like, you know, I mentioned that we also deal with a lot of state clients across thirty five states.
So we also need to make sure that the compliance is there. So that's it's very important that we have some scanning, which can run automation automation fashion. So there is no manual steps too much manual steps, I would say, involved over there.
So and then not only that, of course, one other thing is that we don't want to go into each project and start from scratch, which I was mentioning earlier. We should also then empower the team so they can then, you know, take the practice and deploy in any new project and, take it to the next level.
So what what what was the approach we took? So whenever you're deploying something like that on a gold standard level, you basically have to drive technology adoption from top to down. Because if you start from down to top okay. Okay. Thank you. So if you basically start from the, button, like, from the and then, you know, that will not work because at the end of the day, it's not That's not me, guys. That's them right there.
So, so basic alright. So that's where it was very important. The message goes from the management that, okay, this is the gold standard. These are the set of tools. And not only that, but these are the practices you want to focus on.
So, we started with the DevOps initiative.
We also have the strategy on how we need to deploy that. Because, again, I I don't know how many of you are still struggling with deploying the strategy. You may have tools, but you don't know if everyone is following those tools or those practices or not. So that's where you have to have the buy in from your stakeholders, from your management. You have to ask them to send that message that there is no other way around. And then, of course, select tool wisely.
You may have, again, you may have gear set, you may have other tools.
But wisely means that they are easy to use.
They are, fast, you know, and you are not stuck to something which is specific to the environment or Salesforce environment.
Sometimes, you know, and you can have the backup where, if you lose Salesforce, you still have the backup somewhere on the different cloud, and it's easy to deploy with the DRP strategy, which you were just, listening to in the previous session that that is very important too.
Also, create COE. Again, you have one team or you have multiple teams, you're a smaller group or you're a bigger group, it's very important to have that centralized knowledge. Again, it doesn't mean that all that knowledge and all that empowerment is with that team, but that team basically enable you to deploy the overall strategy. Because, again, deployment or DevOps is not just a tool, it's a strategy. So you have to have that COE with one person, two people, or hundred people depending on the size of your company.
That is the team which will, transfer that knowledge to everyone.
Secondly, you have to define the policies.
You know, either it's the tool, like, you know, code scanning, like, for example. You have to define what those strategies are. If it's care set, again, you know, your branching strategy, that is very important. Because without all of those tools combined together, you all know that it will not be, you know, all that fun stuff will not happen.
So, secondly, train and monitor. So why we are doing all of that?
You know, because we want to have a visibility.
Of course, we want automation. So team teams are autonomous.
And also, we, want that we the management want to see or whoever is managing the team, smaller or bigger group, that how the teams are performing. So you want to monitor and then train them accordingly. That also help you build that either the knowledge base and then establish that knowledge base across different projects.
Lastly, you just keep on monitoring. You don't forget about it. That's why you have that you you build that CoE that you don't forget that, you know, you deploy, you forget about it because what happened is human nature, after some time, people, when they're into the weeds, they forget about those standards. And it happens with everyone. So that's why it's very important that on a high level, metro level, you are monitoring that progress on a continuous basis. You can set up every month, every quarterly.
So and then you have to have those monitoring tools or the tool to have that visibility.
So this is, our current landscape.
So the approach I was just talking to you about, we basically went with that. So if you see right here, it's overall gear set.
It's source control.
It's, you know, it's the, ticketing system, communication, automation with that. Because when some, conflict happens, you need an alert, automated alert for some developers to basically report on that. Also, communication to Slack channels, Salesforce, Teams, whatever you are using in your company, automate that as well. So this one, and I think so this, one okay.
Anyways, so with this into ninety plus projects as of now that, we have implemented, the same structure. But again, sometimes the repository may be different with different clients. And the speed with they're willing to deploy is little different. So that's where, you know, but again, whatever you have learned on one project or multiple projects, it's very easy to then replicate that onto different, with different clients.
And why I was a little bit, shocked on this slide because this was changed, so I don't know if it's still there. Anyways, overall, if you see that we have I already talked about we have more than hundred plus projects, you know, or more than that. Ninety eight percent on the projects we are using the strategy which I was just talking about. So if you see adoption, of course, start from top to bottom. So hundred, you know, there is almost like eighty to ninety percent of the adoption that's over there. Again, the difficulty, which I had on the other slide, so I'm just gonna do a freestyle.
So the challenge is what we face initially was the change management because the change is very difficult for the people to adopt to it. The second of all is, of course, external factors, different clients, their release cadences, their, you know, their tools, from a code review perspective. And, the tools they were using, which were not, you know, not very agile to Salesforce repository.
So those are the things with the challenges we face, plus the communication. Like, again, coming back to the teams on making them understand on the change, on how things can improve them. It may be difficult in the beginning, but it will basically eventually, help them. And so that's where and then, on all of the projects, we have CICD pipelines.
And, again, coming back to the same point, CICD having CICD pipelines does not mean only that you are hundred percent compliant to your DevOps thing. That's why it is broken down into a different thing. Visibility, eighty percent of the visibility is there. So and one of the thing is working with team, we worked on the reporting part of it that, okay, we have multiple orgs. We may have multiple gear set environments. How we can consolidate everything together to give it the management, to give that visibility.
So that's where basically we worked, you know, very closely together and put that overall, not only for one gear set or but multiple gears set or put that visibility out there. So that's there. It's eighty percent there. Again, there is still work which we are working on. Plus collaboration, hundred percent collaboration between teams have increased on each and every project.
And, of course, and again, putting that COE, center of excellence together, that is something, which helped in giving that visibility and having that guidance to each of the individual projects. That has helped a lot. Cultural change, again, that was, again, that comes back to, again, people, people, people, people. That that is something which is, you know, has to come from top to bottom, bottom.
So that has been I would say it's still there. People on board, you know, you train them. There are certain people. It takes time to adopt.
You know? So it's almost we are there. Quality and security using, tools like, you know, different tools for quality, like Clayton and even Gary said that, that has increased a lot because it has given the, visibility. It has given the visibility to the technical architects for the developers.
It has allowed us to stop the code to even go further into the environment.
And, given that scan scanning, feasibilities and automation have totally changed the entire, I would say the strategy on the peer review, code reviews, which the teams were doing on a day to day basis.
And environment, sanity. I'm pretty sure even with having a tool, you may have different environments with different, code base because of whatever reason. So whenever you plug in something, you have to have you have to make sure that the environment are in sync to have that proper QA testing, UAT, and and that's where Gearset helped us a lot on doing that comparison and also making sure that our UAT go as smooth or QA, quality assurance testing go as smooth as possible. That has changed tremendously.
Alright. So, any questions?
Anything?
Yes, please.
Yes. You can. Mhmm.
Yes.
Okay. Good question. So basically, on, when you are doing I don't know how if you're using Gear Set or not, but you you need to have the monitoring and you have the KPIs right now, right? How how long it took, how many bugs were there, how many deployments failed, how long it took to deploy something from one org to the other.
So right now, if you have one org, it's easy to see in gear set itself that reporting metrics. But if you are having multiple gear set or organization so what we did as of now is we consolidated all that APIs, which the gear set provides, and we put it into our AWS cloud and we build the reporting over there. It is so giving that, okay, if this project how this project is doing with the same type of metrics which I just mentioned, and you can filter through the consolidated data which we are receiving from Gearset. You can basically filter through that.
So, again, good question. So it totally depends. Usually, we are automating it. So as soon as someone put a full request, it basically someone either it's auto merged if we are not using that with some of the clients.
Someone as a release manager, for example, review that code and then it automatically deploys into a different environment. But there's some because some of the clients do require some of the, review on what they're doing. So they just want to review and just say yes, okay. Just an approval process. But we are automating on some of the projects. In some of the process, we have approval processes. And on some of the projects, because of the client needs, we are also doing little bit of manual checks as well.
Yes.
So today, we have different tools for automation, test automation. Again, it totally depends on the client.
So what we are doing is from an automation perspective, if some are, manual, some are automated. So whenever you are deploying something, it basically do the testing automatically.
And then after that, if it fails, it stops from deployment also. So on some of the projects, we are doing that. On the other projects, there is a testing team who basically, once the deployment is done, they do the smoke testing, insanity testing, and if it is required, regression testing also.
Yes.
Mhmm.
Mhmm.
Yes. Absolutely.
Yes. Mhmm. It does support Teams and Slack and different channels. And even if you work with them, they will also provide you some APIs for other tools. So, yes, we do.
Okay. Okay. So you can do both. So for example, I'll so let's say a developer is merging the code and the developer received a conflict.
So you can automatically have a deployment channel on Teams on Slack where you can automatically publish that, okay, there is a conflict. Hey, Dima, can you go and check, you know, your code has been, you you have to review the code and conflict and resolve that. For other from management perspective, like for example, if you have a change management team and they want to review what is going on, they're afraid, they basically receive the deployment succeeded, deployment validated type of messages too. So you can tailor that according to your needs.
One more question?
Come on, guys. More questions. I like asthma. Okay. So, yes?
Good question, Adam. So, basic yes. But it it was simple because, without all of the DevOps practices and everything, it was getting difficult for them because some are slow, you know, in deployments and everything, so it's good. But some like, the work we are doing with the, government in, agencies, it's they want, like, things quick, quick, quick.
They cannot stop. So they were feeling bad. So as MTX, when we went to the client and we said, okay, you need to adopt to this, it was very easy for us to pursue it to them, you know. And, of course, with, with the government agencies, it's a little bit difficult because they have their own set and standards.
But again, having the tools like what we have and the practice we have, it was easier to convince them.
Yes.
So the overall, like, Salesforce you're talking about? So, again, it depends on good question. Overall, for us as NTX, because we are a consulting firm, it doesn't matter to us which if Salesforce is pushing us something or is pushing us something, they don't. We try to partner with the you know, where we can basically have someone who can be agile enough to take the product features and also implement for our clients. So we have partnership with both, like, you know, not in a sense of a partnership, like, you know, but it totally depends on the client. It totally depends on what we are trying to do at that customer.
So yeah. But they're not pushing, pushing that, you know, use this, use that. It's whatever we see on YouTube. Of course, everyone pushes their own products. But we utilize again, we have hundred plus project, hundred plus clients. So we, monitor, we review, we do the assessment.
And, and based on that, we recommend the tools. But as of now, you know, while we're at CareSet, but, of course, we are here because they are great partners with us, because there are a lot of recommendation while working with all of these, clients. You know, they have listened to us and and they work with us and they guide us through through all of that too.
Okay. So for two hundred users and two admins, again, you still need a repository. Right? You need to have that.
So sometimes people think, okay. We're a small team. We don't need that. You still need a tool to deploy.
You still so utilize the same thing, like, you know, create as a again, it's two only two people. Like, make them as a center of excellence, for example. Second of all, check which repository your company is using. If they don't, then try to get the right repository, you know, whatever that is.
And then, of course, get the deployment tool. So if you're using Gearset today or no. So utilize the tool, like, for example, Gearset, you can talk to, you know, the team, and then plug that in and plus also review the code. Because even if it's two people, if you were planning to expand on the org, it will be the perfect time to also have the code scanning tool also.
And I think so for smaller companies or smaller, not smaller companies, I would say, but the smaller team also, it is a very right time that you put that in place in the beginning because otherwise, you may suffer, which, you know, in the past life, we sometimes suffered, you know, have not having the DevOps at that time to this scale, like, how, you know, it is being I would say that everyone is realizing now that, okay, we need the tools. We need DevOps. We need this, and we need security scanning. We need something disaster recovery plan.
And they struggle now with the technical debt. So I think so with you, to start off with a small thing, it will be, you know, it will be a very right time, but the same strategy, but on the smaller scale. You still need the tools and the same strategy.
Yes.
So, I don't know the approximate number, but we have, like, seventy to eighty percent of care set engagements. And then we have other clients also for other type of tools also. Yes.
Well, there are multiple. So right now, I don't, like, you know, there are multiple. So I don't think so. Right now, I can recommend one, but, there are multiple as of now.
So, I would say that one of the thing is the AI.
That is the biggest thing, what we are looking at. And also, like, if you see the, you know, the, reporting perspective, we want to expand more on that.
And, we still have the reporting as a consolidated view, but we are still, of course, you know, not hundred percent there.
And, and a little bit more robust on like, we use a lot of test automation tool.
We have a lot of knowledge about that, but also expand on that on how we can automate that more and more. Expand on that on how we can automate that more and more.
So from a again, it depends on what type of security you're talking about. If you're talking about data security, yes. A lot of state clients are okay with, you know, they're, hundred percent is compliant with that. If you're talking about from a metadata perspective, that is, of course, not a problem. And then if you're talking about from a code quality and security thing, that's where tools like Clayton come into the picture too.
All right. So by the way, and just one thing, that you can scan this, and that was in the slide and I couldn't even the slide is not updated. Again, their fault right there. So you can scan this and we do have two packages because we have deployed for so many customers DevOps with different tools and different set.
We can absolutely talk about it. So you can actually scan that, and we can talk about those packages if you want to.
Come on. I'll not bite you.
All right. I'll leave it up here, so if someone and we have a booth there too. So if anyone wants to come there, but thank you.
