Description
In this webinar with Salesforce Ben, hear from Nikhil Reddy (Amazon) and Nicola Greenlee-Scott (Gearset) about how Buy With Prime got up and running with a successful DevOps process.
Whether you’re just getting started with DevOps, hitting hurdles with your current process, or looking to scale your team, this webinar will have tips and tricks to help with your DevOps journey. Including:
- Finding the right DevOps solution for your team
- Successfully onboarding and building a DevOps culture
- Identifying areas for continual improvement
- Staying on top of the latest industry developments
Learn more:
Transcript
Hello, everyone. Welcome to today's Salesforce Ben webinar all about how to build a successful DevOps process. Thank you all for joining us today. Today's session is designed to provide you with valuable insights through hearing about Amazon's experience of building out their DevOps process. The chat will be led by Nicola from Gear Sets and Nikhil from Amazon.
This webinar is more of a fireside chat style webinar, so it will follow an open conversational format. So do feel free to ask questions, share your own experiences, and engage with our speakers throughout the session using our chat box.
Any questions that you do share will be addressed in the q and a portion towards the end of the session. So without further ado, I'll hand over to Nikhil and Nicola who will share their experiences with you. Enjoy the chat.
Hi, everyone. Thank you so much for joining.
We'll get started in a split second. But, Nick Nikhil, do you wanna start us off with an introduction?
Absolutely, Nikhil. Thanks for the call.
Hey. I'm Nikhil. I work as a senior technical program manager at Amazon and buy with Prime segment.
My main focus is on Salesforce and databases. I, build a Salesforce tool and product for sales, product and marketing teams over here.
So, I work with the stakeholders, business, technology teams, and STEs around it, and build the Salesforce system for the sales capability here.
Amazing. I'm Nicola. I'm the community manager at Gearset, and I'm very lucky that I get to work with some of our amazing customers like Nikhil, through our Gearset DevOps leaders program and other community members as well.
So, Nicola, you mentioned that you work with the Buy With Prime team at Amazon. For those that don't know, what is Buy With Prime, and what does your team use Salesforce for?
Sure. So it's both Buy With Prime and Multichannel SolutionMend are the two orgs that I work with. So Buy With Prime is a key benefit that we provide as for the Prime members, for free and fast to deliveries that people already know on Amazon to a third party merchants.
Like, for example, if you're buying from a different website, you can still buy using Prime from that website, if you're a Prime member and you get the products in two to three days shipping, which you which is already available.
So multichannel fulfillment is another thing for the merchants where they can have multiple channels of, like, Instagram, Facebook, Target, Walmart, everything. And they can use Amazon's logistics and shipping mechanisms to ship to the customers, from Amazon side. So these are the two team two teams I work with, and we built the Salesforce, which centralizes, for both the orgs, for sales and marketing teams and also product teams.
This platform, we we launched the merchants on this. We support from lead generations to the post op support, post sales support and post product support as well on this one.
So, this is a major thing. We automate we have a lot of automations around, how to enrich the leads to integrations with third party tools and a lot of other things in in by with from multi channel fulfillment org over here.
Very cool. I do love pride myself.
And I know it's been quite a journey and to get to the process you are you've you're doing today, your Salesforce DevOps journey. What initially prompted you and your team to implement a Salesforce DevOps process?
And how has the process changed over time as well?
Yeah. Absolutely. Our sales ops, again, it was a evolving process. We are still evolving. We started, this org in twenty twenty one.
Initially, we were only a two people team and a small team, and many people don't like to hear this. We were doing a lot of changes in production just going there because, adding a pick list in production is very easy compared to just go through the whole DevOps process and all those fun stuff. So we used to do that, and then we realized it's not the right process, and then our team grew as well, and we are having conflicting changes and, impacting the stakeholders.
We used to change sets, which is also which is already native to Salesforce. We also used SFDX commands, which is more developer friendly.
We used to deploy that, but since we are we are trying to go implement the DevOps process, it did not fit our needs, and it did not support all the, requirements what we're looking at.
And then we had to go for third party tools, and we did scope for a lot of third party tools, and we ended up with GearSet.
Again, like, even though we implemented a DevOps tool, that did not mean that we, we instantaneously went into the final destination where, hey. We have all the pipelines and everything done. We just started using DevOps gear set, and then we just used compare and deploy.
Again, even with that, we had so many issues around, like, people overriding other people changes. They're not having metadata backups and not something around it. So, eventually, the first step was we're doing the metadata backups, daily backups, or every every deployment was a backup over there and use server, version control to do that. And then we moved on to the pipelines in March of twenty twenty four after one and a half year of using gears that we moved. The the journey went into implementing the pipelines as our team expanded, and we want to do ad hoc releases and also do faster releases.
And since March, we have reduced our error rate into production deployments to five percent. We used to be seventy four percent errors sometimes.
The comparisons used to fail. The validation used to fail. So now we're only at five percent errors.
And we have an increase of hundred and thirteen percent in comparing deploys.
And this, this can include from anywhere from automated comparisons to, manual comparisons over there.
And, also, since we used to do, the releases based on comparing deploys in the past, it used to be slower comparisons since we are using pipelines. Right now, we we increased our deployments to two hundred and sixty five percent since, March.
Wow. That's some impressive stats.
So, yeah, quite a journey then going right from doing in production to doing using Salesforce's free feature change sets and then fundamental features with gear set and then right through to this automated pipeline that you're now using and getting all those impressive stats there. That's really cool.
When you were initially looking for a DevOps solution, what was essential for your team?
Sure.
So we were looking for so we since we already had a process of DevOps using change sets in SFDX command, SFDX command says out of the scope because it's mostly developer friendly and not admin friendly, and we have more admins in development team. We also want to have a tool which is user friendly, and, the interface has to be very easy that it has to have a minimal curve and, minimal learning curve work there. And the other one which we felt the issues around were the support.
We we use couple of everyone in the team used couple of other development, and DevOps tools in the past, and the problem everyone mentioned was a support. And we were looking for a tool which has the efficient support and the faster mechanism over there, and this is one of the other tools. And the other thing which we looked at was, the familiarity with the tool. If we are we are looking for a third party tool, then we want to make sure that at least fifty to sixty percent of the team already used this in the past, and this was one of the other thing. And the other nice to have features which we are looking at were metadata backups, version control deployments. And since, we use CodeCommit on Amazon, which is an AWS tool, an integration with, CodeCommit.
And we're also looking for a tool which is independent out of Salesforce, which should not sit in native Salesforce, which has to be outside and should not, because the main reason we are looking around it was if Salesforce goes down, we still should have something which is already backing up or which we can recover from that.
Yeah. There are a lot of other minor things like cherry picking, metadata comparisons, faster, pipelines, so the the a nice to have features, which which Jess said was, aligning with us. And, and also we have our security review already done for some of the teams, which which could, ramp up our speed to implement that tool. So we use this, Gare said for us.
Lot of things for consideration. These are the things that I'm talk I'm just talking about are just on top of my mind. So there were a lot of other things.
That is that's yeah. A lot a lot of things that you have to think of. Yeah. I've been looking looking for a platform.
And you mentioned some of your fifty to sixty percent I think you said, were familiar, with the Gareset platform and you were looking for something that people had familiarity with. I'm assuming it's still with the new platform comes a new process, so you still need to train your team. How did you go about training the team and making sure that they had everything they needed to be successful?
Yeah. Absolutely. They know Gearset, but they did not know pipelines or did not know what are the filters that we need to use because every team uses a tool in a different way that it's supposed to be or they intended to be. So we have our custom comparison filters. We have our custom, metadata syncing to our AWS code commits, which we connected using SSH keys in the past, but then we used AWS keys in the, later or later on. And we also have connects with our account manager on the gear set.
For any major releases happen, we do we did request them to have a connect with us, a thirty minute connect to discuss about the major release that's happening so that our team gets trained. And if they have any questions, they'll ask in that platform.
But any other issues that are going around or any other knowledge gaps we have, we use docs that the, the docs website that the gates provide and also the chat support that I mentioned in the past, like, which was, fifteen to twenty minutes or two to thirty minutes of response time for us.
So so these are the things that we used, to train our team, and we also have some internal documentation on both AWS side, Salesforce side, and Garessard side, how to use all these three tools together.
Cool. And you you enter the three tools there. So you've got and I'm sure internally, you're evolving. You've got Salesforce is evolving. Gear set is changing as well, and we have new things. I know you've worked quite closely with some of the product team, at Gear Set to come up with some new features, and you've given some requests.
What would you say is the most impactful change that you've, sort of been involved with on the Gear Set platform?
So one of the requests that were raised back in twenty twenty one or twenty twenty two, if I don't remember, was around the cherry picking of the biggest value. So since we were used we started using the, the version control. It it it was just compared and deployed. It was very pretty straightforward.
We're just, doing the deployments over there. But if it will if we are using the, version controls, it was very hard to cherry pick. Like, I can develop ten, pick list values and someone can develop five, and we only wanna deploy mine fine and someone else's five. So it was very hard.
We used to go back to Versus code and, manually cherry pick those changes and deploy.
So this was a request, and we requested them. And I know, like, just like some ideas around I we thought it would take a year or two to just build that, but within two months, we got a notification from the product team saying, like, hey. We this already didn't work, and we're going to deploy next month. Do you wanna test it out?
And I was like, that's cool. And in three months, we got the entire cherry picking. And, you know, once someone gives you something, we request more. So I started asking more from there, like, XML parsing issue.
Salesforce has a weird way of comparing the XML formats and the alignment of XML formats. But when you compare, it shows a different, but there's no difference technical. So that was one of the things that we compare.
But, again, these were the these were, like, the minor limitations at the point of cherry picking was a major limitation, and we thought, like, it will not do it. And we were thinking about, some other mechanisms to work around. But since it was done, it was a easier mechanism. Like, we got some of the things that are coming in as, like, compare two point o was one of the thing. Sandbox deployment history is another thing. Again, even though, like, we get all the new features, also, you still have some limitations, which we are still working with the Gearsett, support team, which are already which I already got information from our account manager and the product team that they're already in progresses.
Yeah. Like, a full process is one of the thing and for the pipelines. We got rate limits. Like, again, these are, again, our team specific things, which we are looking at, but Git has a different limitations too.
So That's great.
Yeah. I know, from the product team, you've you really had a big impact. So thank you for, always chatting to them and and, helping us develop the platform.
Absolutely. I know you're also very passionate about, establishing a DevOps culture within your team, but DevOps culture can mean so many things to every different things to different people. What does it actually mean to you?
Yeah. DevOps culture is, again, you just talked about we are not we are we are not just saying a DevOps process or DevOps something. Right? We're talking saying it as DevOps culture. Absolutely. DevOps is a culture, and it's all about, the mindset of how you're collaborating and how you're continuously improving the product and also adaptability of it.
Many think it's the process that needs to be, you know, followed, and that's about it. But it's not about that. It has to be a continuous improvement. It it's all the team come together, following one unified process to make sure the system runs faster, and you're having you're delivering faster to your stakeholders is the main thing that people need to think about.
And, also, many people have an idea saying that, hey. DevOps is just a one process, and it has to be followed in the same way. It's not that. DevOps is not one size fit all approach.
It's not like one size compression socks or something like that.
It it has to be tailored to everyone's specific needs. Even in the let's say, I have a hundred people team and someone else has a hundred people team, that doesn't mean that, the size of the team defines the dev ops process. It's the structure of the team and how your how your stakeholders, get the things delivered is how you build your own process over there. And, again, it varies from smaller team to larger team. It varies from organization structures. It varies from again, it's not a universal solutions. It has to be tied here to each and everyone's approach.
The team has to sit together. They have to figure out how you wanna release something from a development to a production, and all the team needs to sit together and say, like, hey. These are the positives. These are the negatives, and this makes your system faster. This makes your system slower. And, so once they establish it, it's again, it's not the end of it. You still need to improve it improve it so that it's more even faster, and you're delivering it ad hocly to your stakeholders.
You need to think that DevOps is sitting behind yours behind the scenes and doing everything for you.
Okay. So how did you build a DevOps culture in your team?
Again, from your lessons learned. So we did some, again, when I talked about it, we are doing direct deployments and production and moving changes, as needed, which were impacting the stakeholders.
And our team definitely knew that, it's a it's a crucial thing for our team so that we don't, impact our stakeholders since our business is very much fastly evolving. We wanted to make sure that, that this this there was process there. So our team was already in agreement with that, so we don't have to train them a lot on that.
But also said there were some knowledge gaps and, like, how peep like, what is impacting the stakeholders and, how we were deviating from the path of when we're deploying it, like, what are the things that are overriding someone else's changes, and it's increasing the time for the deployment to happen. So these were all the things that, our team felt, again, through through lessons learned, and we had to improve, our DevOps process from there.
And you say that everything keeps on evolving, like nothing's static. So how do you keep your team at the forefront of DevOps best practices?
It's not just DevOps. Salesforce is also a completely evolving process. Like, we are talking for last seventeen minutes. In seventeen minutes, Salesforce would have released something which someone would have not known.
So you have to be on you have to be on the bar to learn the new stuff going on. You don't need to know everything out of it.
My idea around learning anything is, like, you need to know the top ten features that are being released for that quarter for Salesforce or, like, even for any of the tools. You just need to understand it.
And, also, there were a lot of, up see, again, this this this is not just around Salesforce on not just on DevOps. It's on both the parties over there. So we had lessons learned, and we have an approach that we implemented because we were working so much on the project. We ignored, like, what are the Salesforce that are releasing, and we missed a lot of things on the flows that, and these are the new features and all.
So we have a one hour setup for every major release that Salesforce does. And in that dedicated session, everyone comes together, and we go into multiple websites, Salesforce release notes, and then we have already experienced people, experienced Salesforce websites that, like, Salesforce Ben, Apex Hours, and they're already industry experts. They read through the entire release notes, which we don't have to. Like, three hundred pages document, we don't have to.
And we find top ten features over there. We put it in one document that we use here. And then in that first twenty minutes, everyone goes does does the research and put it so puts over there. And the next forty minutes or sixty minutes, we just sit in the meeting, screen through all the features that we think that might be useful for stakeholders or even for our tech team so that we can improve our process.
So this is what we do on the Salesforce. But on the gear side side, again, in the previously, I mentioned that, we have an account manager. We also have the in app pop up that come up. Like, this is a new feature that's released.
And if we find something that's interesting, we post it on our Slack channels saying that, hey. This is a new feature that came in. Yeah. Because it was a lesson learned for us, as in last year, Salesforce went from three filters in dashboard to five filters, and we did not know about it because we never read the release notes for that one year.
And it was very key feature for our stakeholders, which we did not implement it. And because of that, we have one hour sessions.
October is the winter release, and we have, on September thirteen, we have a call with our entire team to just discuss through the release notes.
For the last release, was there something, like, like, big that came out of that one that you you were able to jump on?
Yeah.
So Einstein search, we had, like, custom filters that they built and some dynamic fields and also, something around the flows that our team is using. Yeah.
Cool. Yeah. I've not heard other teams do that before with the one hour dedicated sections, twenty minutes to research.
That's really cool.
It is pretty key because, if you are out you'll be outdated of your technology in a day or in an hour sometimes. And you don't need to deep dive into each and every single feature. You just need to understand on the top level, these are the top ten features that are there. The reason why I would say, like, be on the top ten features is that, like, you might be implementing them, but they might be outdated already.
So with the new feature, it can be a plus for your team or even for the stakeholder. It might be improving the system faster. Like, for example, flows went from, continuous to batch processing, which was a very key in the past too. So maybe you can use these features and make those decisions, to improve improve your internal processes as well.
Very good very good advice.
I'll ask you for another piece of advice.
So those that are joining here today, they're they're looking, presumably, to try and build a successful DevOps process.
What would you say is certainly your key piece of advice to them?
I would say that the key piece of advice I would give for anyone who did not start it, you should start it. That's for sure. And start from the basic just like I mean, again, told you. Right?
We started with the, manual production leads us to the journey of entire pipeline. You don't have to just go through that in a day. You can go through what's working for you. You can start with change sets.
If it's working for you, well, then good. If it's not working, look for another one.
There are a lot of other free tools that you have, SFDX commands and PM tools. Now we can build your own system as well. And then even if that's not working, go to the next step. Look for every third party tool that's available.
Then what is fitting for you? And then I would suggest go pieces by pieces and go through the entire journey, until it it is it will never be end. You have to still have continuous improvement. You should I I would say, like, for every DevOps process, you should have a base, like, dev to production flow. You should have a metadata comparison mechanism. You should have a metadata backup mechanism, a recovery mechanism. You need to know when the changes were there, approval mechanisms.
So and also automations around it. So these are the things I would say, but, again, you don't have to go fast on that. You can just go through your process and make sure that it works and fits your team.
Cool. And you've come a long way with tried through the process that you've already had. Where are you and your team going next?
So we are at, pipelines right now, and we are still thinking to make sure there are a lot of other changes that we're looking at. One is, the sandbox comparison that we talked about.
The next thing that we are looking at is to get rid of our developer and admin privileges from production itself, and we go everything to pipeline.
And we can see how the sales team or the market team is looking at our sales Salesforce are. Because if you are an admin, you can see everything. You know what everything is you you think everything is working as expected unless you log in as a, sales team. So, we wanna go with the system with least privilege model, and these kind of things are the ones, are in the next steps of our journey.
More faster to I mean, more lesser filters, narrowing down the filters and all those things.
Amazing. This has been great chatting through, how you've built your successful DevOps process.
I think we've got some time now for, q and a.
So if anybody has any questions, just pop them in the q and a feature at the bottom of your screen, and I'll start firing them over to Nikhil.
Okay.
One that's come through.
Okay.
What KPIs do you track to measure the success of your DevOps process?
So the KPIs that we looked at, we just discussed around how many deployments we are improving and how many ad hoc releases that we're doing. So we have a two, biweekly release we have, and we also wanna do, on demand releases as well. So the number of releases on demand releases we do and, how fast we can do, those are one of the KPIs we use. And, also, how many errors we're reducing and, reducing into the production when we're trying to deploy. And, also, the other thing which we look at is the time from the build to deploy, how much time we are saving over there, and how faster we can do that.
Okay. On here, what are the what are the drawbacks of DevOps in your experience and where it should not be applied?
Good question. I can think about a lot of drawbacks too. Since I mentioned all the positives, there are a lot of drawbacks too. So, like, for example, if you're trying to deploy pick list value, I was very happy when I was doing it to production because it's a two minute task. Just I like I can do it just like that. But deploying through DevOps, I need to go to dev and QAT, pre prod if you have it, or production. So it's it's a process that takes, let's say, one hour of deployment.
So there are implications around it. There there are issues around it, but we still need to go through the process as it will not override some of the changes.
There are a lot of other things as well.
One is someone's change can block in the initial phases of when you're implementing the DevOps process, if you're using a single branch model. But if you're going to a multi branch model, then no one's changes is impacting other people changes.
Maybe if I answer the question. Yep.
Okay. Here we go. And just wondering, could you mention again the main subsidiary processes? Sorry. Just jump there.
Yeah. What what is that?
Processes of DevOps that are key?
Oh, so I would say that, the starting is, like, having a pipeline management. Like, pipeline doesn't mean that you need to have a process for that. Like, deploying through Dell to UAT to production or Dell to into UAT to pre prod production, whatever that process, that is the main thing. The other thing is to have a version control, like having a Git repositories or anything that backs up your code every time there's a deployment or a dialing backup, however it's needed so that it's easy to recover or you easy to know when a change has happened on one of the values over there. And then, alignment in the team where you can have like, what is the best DevOps process over there. And that, I know, again, like, how you're deploying, when you're deploying, like, how you can deploy it, and how your team gets informed, how your stakeholders are informed with the new releases too.
Cool. Did you evaluate using the out of the box Salesforce DevOps offering?
Code like, you're talking about ChainSet or, SFDX command. We use DevOps center. Yes. We did look into that, but chainset doesn't, connect to the git or code commit over there. So we had to ignore that.
Yep.
Which is the best environment for introducing approval mechanism?
Great question.
So I would say that it depends upon how your pipeline is. So our pipeline is, Devs. There are every Dev and admin has their own individual sandbox, then we have an integration sandbox where it's a blanket sandbox where everyone deploys the changes and see if they're conflicts or not. So the next step is just creating the direct PRs into the UAT, and that's where we introduced our approval mechanisms.
So the approval mechanism should be right at the full Apex classes runs. And at that point of time, I would say it's the best mechanism to have the approval processes.
So full runs is a full run sandbox is the one that that you you you need to use, for the approval mechanisms, and it has to be a full sandbox too. I would say that because all the data, do produce different results compared to, no data sandboxes.
Okay. I think we've got time for one more. So I think this one, do you feel that having a separate team slash function defining and designing DevOps important, or should that be handled by release management team? I e, who should own this?
Quick question.
So I worked in both the, settings. One is in a release management setting, and one is a DevOps process through the entire admins and developers doing that process too. It depends upon how the org is built.
But I would say that it works best on the both worlds.
You don't need to have a separate team, if you if your admins and developers are capable of doing the entire end to end process.
But also, again, it depends upon the team size too. If there are hundred, people and multiple dev teams, having a centralized release team would make sense. But if it's like five to ten devs in one team setting, you don't need to have a separate release team around it. Again, it depends upon company to company and team to do. I've worked in both the settings. Right now, our setting is devs and admins do their own releases over here because they know more about their components than the next person reviewing it.
Makes sense.
That's all we've got time for q and a wise, but there have been a lot of questions coming in. So we'll probably put these to you, Nikhil, and then include we'll make sure responses get back to those who have asked, or in the the email that comes with the recording.
So I'm gonna hand back to Simon now. Thank you so much, Nikhil. This has been a great conversation. Thank you so much.
Thanks, Nicola. Thanks, Simon.
Amazing. Well, thank you, Nikhil, for taking the time to share your experiences, and also Nicola for leading the conversation.
And thanks everyone in the audience as well for coming and sharing your questions as well. I hope you understand a bit more about the DevOps process and how you can implement this successfully in your own company and or workflow.
Thanks, everyone.
Hopefully, see you soon at the next Salesforce Ben webinar.
