Adopting Salesforce DevOps: A journey from Admin to Engineering Lead

Share with

Description

Catch up on this webinar with Marco Pinder (Salesforce Engineering Lead, Ninety One) from the Gearset DevOps Summit 2022, whereby Marco takes us through his journey adopting Salesforce DevOps — from starting as an admin to his current role. Marco shares:

  • Why you should start with Salesforce DevOps
  • How to approach adopting Salesforce DevOps and key focus areas
  • The right technologies to enable DevOps
  • Career elevation, and much more!

Learn more:

Related videos:

Transcript

Thank you. Thank you, Het, and everyone.

Thank you for the introduction. So yeah. So, I want to take this opportunity to to talk to you all about, my own personal experience of adopting Salesforce DevOps and what that meant for me and my journey from transitioning from from an admin and a sort of technical BA into, an engineering lead now at ninety one.

So my name is Marco, obviously. I have over twelve years of Salesforce experience in always in financial services, actually, and specifically in asset management.

And more recently, in the last few years, I now have experience leading a Salesforce DevOps transformation, across a global team. So I'm quite excited to to share that with you and and how I approached it.

So I thought it was quite apt seeing as the company I work for. Actually, the roots began in South Africa, so I thought I'd start off with a a nice Nelson Mandela quote. The fact that it it always seems impossible until it's done.

So this is how I felt before beginning, the DevOps journey, Salesforce DevOps journey at ninety one. It seemed quite a daunting task. And just for a bit of context, you know, we've we've probably got about a a twelve year implementation of Salesforce at the moment.

And through the years, there have been, you know, many people involved in that. We have outsourced development to consulting partners.

You know, we've had in house BAs, in house admins, and what have you. And, you know, people come and go, processes, you know, change. Documentation is always light as as I'm sure you can all attest to.

And so, you know, taking a step back and and wanting to do a digital transformation around DevOps, it felt like quite an impossible task at the beginning, but it really isn't. And I and I want to show you why that's the case.

So the main reason is is why why start this. And as you can see on on with a couple of these bullet points, so my experience was that we had a growing team with with varying skills. So a few years ago, we, we stopped working with a sort of consulting partner that we outsourced our development to, and we decided to to bring some of those skills in house and hire internally.

We had varying degrees of of expertise. You know, we had some people that were sort of well skilled Salesforce developers.

We have those that are admins and and sort of, you know, very with sort of declarative functionality and the point and click, and some strong BAs. And it's a case of how do you actually bring all of these resources together and make sure that you're able to successfully deliver this transformation?

With that, obviously, we've got this maturing Salesforce environment with an increasing demand from the business.

And so I was at the time, I was sitting sort of amongst my peers just thinking, you know, there is something that needs to be done here. And and, arguably, you know, there's maybe it should come from the top down, but, also, I work for an organization that is, very, focused on their culture, and they they like to, encourage that freedom to create and that ability to actually sort of from the ground up and and sort of be be sort of, you know, employee led initiatives and transformations.

So I took it upon myself to recognize the need that there was the need for more structure and more process, And it just so happened to coincide with a digital transformation that was happening across the entire IT estate at ninety one. We had a new CTO, and when she joined, she she was, advocating for, you know, an ad a proper agile transformation at the organization. So it's sort of just nice coincidence, and it happened at the right time.

So my approach for this was to to research what DevOps really means, and there's, you know, there's an abundance of, content out there. I mean, you know, if you're scrolling in LinkedIn or, you know, reading various blogs and and all sorts. You know? There's it's, you know, it's a it's a big topic and has been for a number of years, but it seems that it it's gaining a lot more traction sort of in the in the Salesforce space, which which is why we're all here.

So I I was thinking, well, how how should we approach this? How can I actually sell this to my to my colleagues? And how can we actually begin this? There there must be a problem, that that we're trying to fix.

And for us, that was the fact that, you know, we were we were starting to override each other's changes when we're deploying. You know, we we were at the time, we were still using change sets. We were just, you know, sometimes we were buttoned up against each other when people's changes were conflicting and so on. And I'm sure that these are some struggles that there's a lot of you on the call. You're either you're either have those those challenges today. You may have had them in the past or or, you know, you may be looking you may be on this call looking to actually remedy some of those.

So I was consuming all of this content, and I needed to identify that journey that was ahead and how can we actually, you know, try and do this transition. What what is it that is needed to to do?

So there was some really interesting content out there, and this is what worked for me. So I just wanted to share these because these were the key sort of focus areas, because it's not just about the tooling. And, you know, we're here on this this CareSet call because they they have a fantastic tool, that I'm I'm happy to talk about and and sort of we've had great success with it, and you'll see why in a moment. But it's not just about the tools.

You know, there are other things involved in this. It is about sort of the, you know, the the the structure in the team and the that sprint calendar and the various ceremonies that you can have collectively if you're not doing those already. And then another large part of it is about the change management, and it's not just the change internally with your immediate colleagues that are working on the Salesforce platform, but it's also perhaps working with your own business partners across IT perhaps if you if you sit within IT. And and I'll touch on that in a moment when I get to my change management slide.

But it's it's about sort of engaging with infosec and educating them on what it means to actually build on the Salesforce platform. Because, at least in my personal experience, you know, you have some of these centralized IT functions that might have quite a narrow view about what it means to actually deliver change in, you know, software change, basically. Not not because they they mean to, you know, be blinkered and and and not know the the big picture, but, you know, Salesforce, we're almost lucky in the sense that, you know, we're we're constrained to, you know, changes around, you you know, the the metadata dependencies and the the, you know, the fact that, you know, if you really want something to work, DevSecOps, you know, the the security side of change is almost embedded in and baked into everything that we do and build on the Salesforce platform.

And some of these concepts, are things that are only becoming hot topics these days.

And then the other part of the change management is is, of course, you know, educating your your business partners as well on telling them that, actually, you can't just ask for something ad hoc and and you you might have got it delivered quickly previously and but it wasn't really following best practice. And, you know, we were cutting corners and not doing things right. So we might be slowing down our delivery, but it's gonna be good, robust delivery that we're going to give you, and we're gonna give it to you on a potentially on a regular basis depending on how you have your sprint set up. And so there was an element of educating the business on what this change, what this DevOps, evolution meant from the from Salesforce perspective.

So the Salesforce toolbox was was something and I think this I actually actually took this idea from a a gear set white paper perhaps, or at least a video that I watched a number of years ago. And it was about understanding whether or not you have the right technologies to even enable DevOps to begin with.

And so you can see on on this table here, there were a number of sort of areas that that that almost need to be ticked off. It's almost like a checklist where, you know, do you have a tool that is gonna help and facilitate the the planning side of DevOps, Your issue tracking, your source control, all of the things that are listed here. And at the time, we found that, actually, we we already had a number of these things in the door. You know, we were we had Azure DevOps, which is what we're using for our for our planning and our sprint boards and so on.

And for our issue tracking, we're using ServiceNow for our incident management. We're very much a big sort of Microsoft, shop as well, and so we're using Microsoft Teams for communication, and and we actually have on Confluence as well. But there were pockets around, you know, how do we actually streamline and and improve our process from Salesforce delivery perspective, and how do we actually, do you know, manage some of these items. And we found that where the gaps existed, you know, there were there were tools out there to help us with that.

And, you know, we're we're very much a lean team, ninety one in in the way that we we operate, which is which is great in some ways. You know, we get a lot of exposure to to various technologies and and processes and ways of doing stuff, but it also means you don't have a huge amount of time to go away and sort of build your own pipelines, for example, within within Azure, DevOps. You know, you sometimes you might want to just reach for something on the shelf and, you know, premade product that has all the bells and whistles and some great functionality.

And, you know, gearset gearset is one of those options, and and that's the one that we landed with and and we've been extremely happy with for the for the last few years. But it was a case of sort of building this toolbox and being able to present this back to the team to say, look. We are in a unique position to have the technologies to to enable DevOps from from that perspective.

Obviously, there's I I touched briefly on the on the sprint calendar and the scrum ceremonies. And, yeah, again, there's a lot of information out there. I'm sure a lot of this is not new to to a number of you on the call. For some of you, it it may be, and it you you might wonder what what this means in in the big picture.

But absolutely go out there and sort of swap up on on some of the terminology and some of the concepts. And you don't have to follow these things by the textbook. I think that's also something that I've learned sort of during this journey is that there's there's, you know, there's there's a lot of ideas out there and a lot of sort of people's opinions and ways to do things. But, also, it's it's, it is about being, having that agility and being flexible and adopting the things that actually work for you.

It might be that daily scrums don't even work for you. Maybe, you know, you're a small enough team where there's just a couple of you, and, actually, you just need to check-in maybe every other day, for example. So you don't have to follow these things by the book. It there's more some some guiding principles, but they are they are ceremonies, and it is almost like a a framework to just help you improve and get better.

And and, every iteration, you just you you you're ultimately delivering better for the for your clients.

Another thing that we had to obviously decide on as part of the sort of the the DevOps adoption and and transformation was a workflow model and, you know, branching strategy about how do you actually deliver this. So, I mean, this this was a challenge in itself, and and perhaps I'll spend a little bit longer on this because some of these concepts might be alien to a number of you. They they certainly were for me at the very beginning, Because, you know, traditionally, you know, working with Salesforce, if you don't come from a true development background or, you know, software engineering background, you know, you might not have been exposed to source control before.

So it was you know, the first thing was actually educating, the team, you know, my colleagues about what is source control, what does it mean, and what does it mean from a Salesforce perspective. You might have heard some of your colleagues talk about it when they're, you know, full stack developers and they're building their own applications from the ground up. But, actually, it might not be something that you've ever been exposed to, particularly if if you've only known Salesforce.

So there was certainly sort of an upskilling path there, and and there is some good content. Trailhead, I think, has some stuff on specifically on GitHub. But a lot of the concepts transferable no matter what source control, tooling you use.

So, you know, back in the day, we we initially adopted the something called the Gitflow workflow model. There's a little image of what that looks like there. I think I ripped that from maybe the Atlassian website or something like that. But, it seemed to be a really good fit for us initially. It was it was it spoke about, you know, scheduled release cycles, maybe every two weeks or three weeks.

And I I encourage you to sort of go go away and and read up on that. And we we had some some partial success with that, but I'm saying probably only about seventy six percent success. I think that we really struggled with some of the technical areas around sort of releasing and without in in the absence of a dedicated release manager, which again is is a luxury that probably a lot of us don't actually have it in our teams, particularly in the early days if we're looking to to go through this DevOps transformation.

You know, some questions were coming up in the strategy around who will backfill changes into sandboxes.

And at any given time, we we couldn't really tell what environment the change might be in if people weren't, you know, staying on top of their, you know, the the DevOps board and actually updating their their user stories and their their work items, their tasks, and what have you. So it it just transpired that that we felt that it wasn't really quite the the correct workflow that we were using. So earlier this year, we sort of reviewed the options that were available. And, again, just coincidentally, GearSat themselves, have released a a pipe a pipeline branching model. Excuse me. So this is some new functionality that came out.

And when we looked at it and understood exactly what it gave us, both some visual visual side of it, which I'll I'll have on screen in a moment, but also some of these challenges, again, that we were facing before about backfilling, changes into sandboxes and understanding what environment you know, what what is the work in progress, you know, in in flight. Is something something currently in QA? Is it currently in your UAT and maybe in your full copy sandbox and what have you? It give you it gave us a great sort of visualization of that and good insight. So I felt that the pipeline functionality just added that transparency to our process. So it was something that, we really get to jump on, and I think we've been using it since since early June ish, June, July time.

And, you know, we we wouldn't go back as a team. It has been game changing for us in in in the way that we actually release and the speed with which we can get changes into production.

Yeah, which has been fantastic.

So one of one of the other items I had there about the the DevOps transformation is is obviously, it's around sort of your your development, your CI, and your testing. These are all sort of, you know, areas to to to not be ignored.

So one of them is obviously coming up with a sandbox strategy. Again, you might all sort of have, you know, a number of developer sandboxes, again, depending on your Salesforce slides licensing and so on. You know, are you refreshing them frequently? Are you if you've got multiple sandboxes, could you, you know, hand on heart, say that all of your sandboxes have got the correct configuration in them that all of the other sandboxes have and, you know, when it's appropriate to do so if it's, you know, not too early in in the sort of development process.

And and the CI side of it, you know, how can you actually get that continuous integration? How can you automatically deploy perhaps into your set into your various Salesforce sandboxes?

Frictionless. You know, there's obviously, we can all do this with change sets, and there's a perhaps a lot of administrative overhead to do that. And and I'm sure we've all fought with change sets and tried to deploy something and forgotten about it where there's, you know, none of that dependency checking is done for us. And these are all things that Gizet have really, really assisted with.

And here is actually a diagram of of what sort of our pipeline looks like at ninety one. We've got a couple of product teams, if you'd like to call it that, that are sort of working on the platform. And the release training is, you know, we're we're all going into a into a QA environment. We're all sort of testing there, within promoting into our our user testing environment, which is our full copy sandbox so that we can actually get users to you to sign off before then, deploying into production.

And we've also got a hotfix environment in case there are those, you know, very infrequent emergency changes that need that need to go in. But just this visualization here, I don't I don't know. Apologies. I've I joined the call a bit late.

I was actually commuting back home from from London, at the at the beginning of this call. So I don't know if if much of this has been discussed, so far in the call. So apologies if I'm repeating anything. But, again, just this this here has has been game changing for us in terms of visualizing what change is going on in the Salesforce platform.

Yeah. It's been fantastic. And then finally, testing. I mean, it's it's something that perhaps we we don't consider too much very often.

It's at least, me, my own admission is that in the early days, you know, testing was something that I always thought about thought was, you know, a developer issue to worry about. But the way that you can set up these pipelines is that each time you're doing a deployment, even if it's just a small bit of config, you are running all of your unit tests upon deployment.

You know, you you can set up your your continuous integration jobs to do that so that you know that the the the feature that you're shipping or the small piece of functionality, whatever it happens to be, is not going to break something in that target environment, at least not from a, sort of a code base and, you know, from a dependency perspective. It might not be exactly what the user wants, but, hopefully, you'll you'll find that out in in UAT or or earlier even.

There's also the element of, you know, trying to encourage people to follow this process.

Do not, you know, something that that I've personally experienced is that no matter how many times sometimes you tell someone not to do a change directly in production or directly in a different environment, you know, you must begin your development earlier on in process, and we actually have a, you know, we have a a framework to allow us to get that change through into production successfully. You know, people will still bend the rules, and they'll still do what they need to do. So you want to you want to ensure that people aren't actually going into those environments making small changes here and there sort of on the sly.

So you can set up within Gear Sets, again, just to sort of, you know, highlight some of its, great benefits is that you can set up daily testing of all of your environments just to make sure that there isn't actually any config in there that will break. There's all obviously metadata monitoring as well, which I'll go into in a moment. But even just setting up those daily unit tests. So even though you're testing while you're deploying, you can also regularly test your environment just to make sure that no one's introduced anything, that's actually gonna break an environment, and cause problems in the future because of the sorry.

If I just go back a second. So one of the worst things is if if somebody does, you know, unintentionally maybe forgets and makes a change, say, in one of the environments. Obviously, you know, permissions and and trust is a a separate issue at the moment. But, you know, if they do make that change, you don't want it to then impact anything that is waiting come into that environment.

I mean, let's say somebody makes a change on a Thursday, and inadvertently causes unit test to fail. You know, they might have changed the validation rule directly in production, and it just so happens that, you know, some of your unit tests are aren't aren't configured now to to actually, validate that, you know, that change that's been made in production. And you might have a release backed up and and waiting to go in on Friday, and you don't want that to happen. So the earlier you can catch this, the, you know, the the the failure of unit testing in the environment, the better.

And Salesforce, gives that gives you, some tooling to do that, which has been fantastic.

And then the monitoring. So touching on that again. So not only are you running those unit tests each day, but being able to monitor metadata changes, and this has been fantastic as well.

So, you know, you can you might expect certain elements of metadata to change and and allow them. So take, for example, list views or reports or dashboards. You know, these are all elements of metadata that you could put into source control if you wanted to. And some cases, you you know, you you would do that.

But it's also an element of metadata that you may allow to be configured by users in your production environment. You might allow some, you know, some super users or some, you know, you know, more, mature users of the platform, but aren't part of the Salesforce team. You might allow them to make some of those changes in production, but you don't want those to be sort of a a false positive, when you're monitoring the environment. So you can actually focus your monitoring, against your production environment to say, tell me, you know, alert me if if some sort of change has happened without without our consent or without knowing that there was going to be a release on a given day. And it, you know, it can flag up some of those issues if you've maybe got some some personnel trouble where people are making those changes. This is a great tool just to give you that insight without having to go and look at the the audit log and the history of what's being changed in the environment.

So you can be very sort of specific about the metadata that you're following, and you can get it to even, you know, put out messages into Microsoft Teams. You might have a Teams channel that tells you about, you know, your monitoring that's going on in Salesforce. So I actually I do have that. We have a we have a nice sort of Salesforce team, set up in Microsoft Teams, and we've got I've got a dedicated gear set channel that I'm actually publishing alerts to on a daily basis when we're monitoring our environment, both metadata changes as well as our Apex, unit tests, which has been fantastic.

And then there's peer review. So that that's also an element of being able to adopt this successfully is that, you know, there might be it it might be appropriate to introduce the concept of peer reviews if that isn't something that already exists. So some you know, if somebody is is now getting familiar and I say with using source control and and sort of, you know, committing to their feature branch, raising pool requests, you may then start introducing peer reviews and say, well, okay. Well, before we actually approve something, I want one of my other colleagues.

Otherwise, you know, if if people aren't looking at the change that's going on on the platform, it's like marking your own homework. You know, you you you think there's nothing wrong with what you've built because you built it. But if you actually put it under the eyes of somebody else, they might be able to flag something for you that you didn't you you didn't think of at the time. So peer reviews is also a great tooling around or a great, option around monitoring.

And change management. So the change management piece that that for me, as I mentioned earlier, it's about, managing that messaging for your immediate colleagues and bringing them along that for that journey and and educating them on what it means to to go through that DevOps transformation. And, again, just touching on some of these things around, you know, taking taking infosec and IT risk on that journey with you and just making sure that those centralized functions know what it means to build on Salesforce and then have that DevOps process in place.

And so for for me personally, just, I can see Tony's back on, so I'm gonna start wrapping up a little bit quickly. So in terms of your career elevation, so this for me was my story about going from that admin, that sort of, you know, the the and I don't mean to sound just sound a negative perspective, but if, you know, if you want to further your career and start to sort of evolve and and sort of grow in your role and look for the next thing, it is opportunities like this to introduce DevOps that actually gives you that career elevation. And I think because I was able to deliver on on the intended result from the outset, You know, you become trusted by your peers. You become that subject matter expert, on the Salesforce platform within your organization.

And it for me personally, it's allowed me to transition into an engineering lead. And so, you know, with that, it comes, you know, what's next. So, you know, as the team is maturing, for me personally, again, sort of the next step is is looking at that center of excellence. You know? How can we actually instill that governance and and that framework? How can we have architectural reviews for the rest of the team to make sure that we're all joined up? You know, we're all building according to best practice, whether it's, you know, Salesforce recommended best practice or whether it's some things that have, that that we have decided upon, you know, internally at ninety one on on the way to do things.

And then finally, just to touch on the few of those other things there, you know, then some of the other things that I would like to now expand upon is, the DevOps research assessments metric metrics. So this is the the Dora metrics. And, again, luckily, Gearset has has done some work in this space. So there's some reporting available.

They've got a new reporting API where you could start understanding, you know, how fast you're actually getting changes and delivering them into production. Like, what is the speed of that? And, again, for me personally, it's about, you know, where are we today? What is that situation?

And and then how can we improve on it incrementally?

And I heard Ian actually just just before he wrapped up earlier about talking about that shift left. So that is also some some concept that that is, that I'm sort of understanding more and more, and it's about sort of if you look at that pipeline view, I mean, some some of you might not know what shift left means or overheard that phrasing before. And I'll I'll be quite honest. It's it's relatively new to me as well.

But that pipeline visualization that I had up earlier, it's talking about making sure that security and and things like that are not left too late in the process. You know? Everything is kept to the left hand side of that pipeline. That's what that shift left means.

So think about the security. Think about the analysis. Think about everything as early in the process as possible to the left of that diagram.

And then finally, just to touch on this static code analysis, stuff that is that is also possible as well. But that's a little bit more techy and, yeah, something that I I have some interest in as well. So, Yeah. I'll pause there.

Sorry. I'm not I haven't been following too long. I think I'm only a couple of minutes over, Tony. Sorry.