Talent Hub is proud to introduce a Podcast version of the seventh episode of the Talent Hub TV series. Here, Talent Hub Director, Ben Duncombe sits down with Salesforce professionals and thought leaders to learn more about their fascinating stories and market insight.
Adam Best joins Ben to give insight into DevOps within the Salesforce market. He shares with Ben how he originally became involved in the Salesforce space and what specifically has led him into the DevOps niche. He explains the benefits of such a model, and how it can work efficiently to save time when removing manual steps.
Talent Hub Director, Ben Duncombe, chats upskilling, useful learning resources, and of course, Adam’s upcoming session at the one and only Dreamforce.
If you’d prefer to read this insightful episode, you can find the transcribe below.
Ben: Welcome to Talent Hub TV Episode 7, we’re here with Adam Best today. Adam’s a long-term Salesforce professional who’s currently working in one of the biggest Salesforce environments in Asia-Pac, so we wanted to sit down with Adam and talk about his career and some of the things he’s been working on recently. So welcome Adam.
Adam: Thank you, thanks for having me.
Ben: Can you tell us a bit more about your background and life before Salesforce?
Adam: Yeah absolutely. So I guess I started my career as a junior accounts receivable person. And soon found a knack for I.T and ventured into I.T very early on. I guess background technologies is SAP, the old R2or3, and then a bit of open source through the early 2000’s, and Sugar CRM. Before someone tapped me on the shoulder and said ‘ hey, come work on Salesforce’.
Ben: Okay, and when was that?
Adam: I think 2006/2007, just to the turn when they put in custom objects.
Ben: Sure, and what was your initial role and exposure to Salesforce?
Adam: At the beginning, it was working with a good friend, who, we went into business together as a small consultancy. Just implementing small to medium business. And then obviously venturing out to the Tier 1’s.
Ben: Okay, so what are you doing now as your current role?
Adam: I’m currently a Solution and Delivery Architect for one of the Tier 1’s here in Sydney, and that involves standing up the DevOps, running DevOps, quite a large team. Supporting preprod, as well as, so the delivery of the features as well as the provisioning of the boxes coming back, so it’s three Enterprise releases at any one time concurrently, in SIT and UAT and yeah, lots and lots of Devs.
Ben: Sure, okay and when you said Tier 1, you don’t mean consulting to Tier 1 banking right, so you’re you’re not in the consulting world any longer?
Adam: No I actually work for an end customer in the financial services industry.
Ben: Okay, so you’ve kind of made a niche for yourself in the DevOps world, so DevOps within Salesforce. So what does that mean, what is DevOps within Salesforce, what is it, what can you tell us about that?
Adam: Absolutely, so I guess when people think about Salesforce they think about a Developer, and a Functional Consultant. They think about building the features, and usually they will do change sets out to production. DevOps is really taking that next step and saying ‘hey, we’ve got, you know, multiple teams, you know, tens or sometimes hundreds of Developers, and you’ve got a waterfall style release cycle, where you have to join other projects, so it’s really taking DevOps to, it’s really taking Salesforce to more of a CICD solution, so that you can jump your feature across multiple boxes, the delivery out to production. Equally as important, it’s actually provisioning those build teams with the tools and as your coming back as well, so it’s getting that Dev box stood up, you know, pretty much instantly. Time is money, you know, so a if a team gets stood up and they need tools, you need to get that Dev box out to them with things like passwords removed, data in there.
Ben: Okay, so you come from a development background, and now you’re operating as a true specialist, and pretty niche into that DevOps space, so how did you make that transition and why?
Adam: Yeah absolutely, so I guess I was lucky because my background industry, Sugar CRM, was more of an open source, it was on a Linux box, we did have to understand, you know, the infrastructure behind it, so it was a really easy transition for me. I’d already had experience in another vertical, on another application, so I just applied those same principles to Salesforce.
Ben: Sure, and was it like a strategic move, you could see that the Salesforce projects and environments were getting bigger and therefore that they would need people like yourself?
Adam: I don’t know whether it was strategic, but it was a natural move, I have a passion for DevOps, I have a passion for delivery, so it really just came, you know, side by side with that passion. I saw that it wasn’t done well. And I wanted to do it, and I wanted to do it well, and I want everyone to do it well.
Ben: Sure, right, so what about tools, and to learn, to pick up the ways in which you become a DevOps specialist? Are there tools out there, like, you know, how you have Trailhead for Salesforce Developers, is there anything you could recommend to people?
Adam: Yeah, there is a little bit, there’s not too much, I would say if you’re not a Developer, you’re more likely going to have to go round an App Exchange route, such as AutoRABIT. If you are a Developer in a larger organisation, you’re probably going to have Enterprise tools, Enterprise CI/CD tools for that organisation. So it might be GoCD, Bamboo, Jenkins, so really just using those tools and then getting the metadata API on top of that.
Ben: Okay. So what does your day look like, your role currently, what does it look like day to day, what are you doing on a day to day basis?
Adam: Absolutely, so my sole job is to make sure that we save time, and to make sure that the teams aren’t down, you know, for any instance, and to make sure we’re delivering the features out to production, so primarily one of my roles is that I’m making sure that we reduce manual steps, you know, going out to production, I’m making sure that we get a better Dev instance for the build teams, so just a lot of scripting, supporting the build teams. And supporting the business going out to production.
Ben: Okay, and is DevOps something that all companies should be thinking about now, or do you need to be a certain size, have a certain amount of Developers, what’s the right kind of time to think, ‘right, now DevOps is, yeah, it’s a play we need to make.’?
Adam: In my opinion everyone needs to think about DevOps. Whether you have two people in your team, you can always, everyone’s building, so you can always actually test that build, you know ten times a day, every half an hour, every hour, so that you get quicker out to production and you don’t have, you’re not stumbling over yourself when you’re hitting production and validating. Definitely for larger teams. You can’t give the business options of when they need to go out, what code needs to go out when, if you don’t have a platform to do that, so everyone definitely needs to think about DevOps. GitFlow branching methodology is my favourite, and making sure that you are delivering out to production the right code for the business when they want it, as well as making sure that you get the boxes back with updated code for the build teams to build on.
Ben: Sure, okay, so a company decides, ‘right, we’re at the point now, we’re going to start thinking about a DevOps plan’. What are the considerations, what do they need to kind of have in mind?
Adam: Yeah, well firstly you need a DevOps Architect. So, someone to get in there and formulate a plan, find out the current processes, so that you can tweak those processes to reduce the impact on the team. Find out what Enterprise tools the company is using, use those, or introduce some that front into Salesforce, and then once you’ve formulated your plan, making sure that you move everyone in the same direction at the same time, so getting up a Developer Onboarding guide, to make sure everyone’s comfortable committing, upskilling people who can’t commit, subversion control, and then having a phase approach, so phase one might be putting CI/CD in the build phase, and then slowly releasing that out to, to SIT and UAT and production. Once you’ve gone out to production then you can come back and have a look at your provisioning of your environments, to make sure you’re getting out the passwords, filling of data and other tools. What’s an issue tomorrow, it might not be an issue today. An example might be that as your team grows, you’re going to spend more time on giving people access, create a proxy tool so that they can go and give themselves access to boxes they need to.
Ben: Okay, so on that upskilling piece, people that haven’t come from an environment where DevOps is a feature or focus, and the tools that you’ve just mentioned that they need to learn and kind of get used to working in this way, how have you found that upskilling piece, are most Developers able to pick up the processes and the understanding and the theory behind it?
Adam: Yeah, absolutely. Both onshore and offshore. So if you make a process really simple, if you have some screen shot instructions to say ‘hey, you know, here’s a typical day in the life of a Dev in our company, this is how you commit code, this is how you request access.’ So it is really, what I call a Developer Onboarding guide. So everything you need to do your work, is really in that guide, and that guide isn’t a write once and forget about it, that guide is forever being changed and being improved, even to the point of, in your organisation, you might not commit to metadata because of security reasons, maybe you don’t commit connected apps, or no credentials, and so you would then, have almost like a cheat sheet of what you commit and what you don’t commit. And then as new Developers come on board, maybe you have them come on board in groups, or they come individually. You then obviously offer training sessions or a training video, so that they know how to do things in your particular build environment.
Ben: Okay, so from going from environments that perhaps didn’t have the procedures and policies in place, to now working and putting these plans and procedures and policies in place, what successes have you seen companies have with a clear and defined DevOps plan?
Adam: Yeah, absolutely. So reducing manual steps, which is obviously preserving the path production, and better repeatable steps, by a factor of ten, so you can literally reduce steps from one hundred, even two hundred sometimes, down to just ten or fifteen. You obviously can eliminate regression issues, so where you might have regression issues, because of those amount of manual steps. Being able to multi-stream, so being able to offer the business the ability to run, multiple streams of build, and multiple streams of SIT and UAT at the same time, and ultimately saving time, which equals money. The culture of a build team, as well is really important, so getting every single person in the team excited about ‘hey, we’ve got to make sure that we keep our build green, we’ve got to make sure we commit with code’ and not just kind of thinking ‘oh you know, that’s too hard, let’s chuck it on a run sheet and do that as a manual step’. If you have one manual step in your particular feature, as you join other teams, it compounds and if you’ve got three concurrent releases. If you’ve got twenty, thirty and forty environments on your end to end, you might do your manual step ten times going out, but compounding, it’s all the other boxes when they consume the latest production code and so it could be thousands of times that you do that manual step.
Ben: Okay so let’s talk Salesforce DX. What’s that going to mean for the market, and what have you been playing around, if at all, with DX?
Adam: Yeah, I have been playing on DX a little bit. I think the maturity of the market needs to understand what DX is, and how that’s going to change the landscape of the organisation. So DX is a source control build tool. It’s not a source control delivery tool, so you actually do your changes on your scratch org, which is, by the way, is a vanilla version of Salesforce, not your traditional sandbox. And then that’ll sync nicely down to a source control repo. You can definitely use DX going out as a delivery tool, but it’s not a source control delivery tool. It’s kind of like a beefed-up change set where you can combine multiple artifacts which are essentially change sets going out to production. The value in DX I think is phenomenal. As we just discussed earlier, you’re gonna have to skill up, even your declarative designers on source control, but I think with DX we can take that away, and if you put CICD in, coupled with DX, you can have a declarative designer, you know, say ‘add a field’ and then instead of having to pull down the field, the object, the profiles, permission sets, any layouts, DX has a command which is called a pull, and will sync that down to your artifact, so I think it’s definitely going to reduce build time, by up to 20% I believe. The other value is that obviously you’re going to need lower skills. You’re not going to need source control skills for the majority of your team, so that’s going to save a bit of time and money upskilling, and maybe some money on lower skilled resources as well.
Ben: Sure, and what about as a Developer looking at DX, what should they kind of start to think about?
Adam: Yeah absolutely. So I think the Developer needs to understand that DX is a command line interface today, it does have some cool, there are some cool, you know, GUIs out there AutoRABIT will have a nice GUI, there’s some extensions on visual code. Which I use, I use visual code. So yeah, just get in and have a play. You do need a production license in your organisation, so enable the Dev hub, run up a scratch org and just have a play and see what you can do.
Ben: Okay, cool, and anyone that’s watching this thinking DevOps is the way for me to go, potentially from a Salesforce development background, what’s your advice?
Adam: If you’re passionate about DevOps, then yeah, I guess the name of the game is automation, so make sure you get that delivery out, you know, without any regression issues, making sure your build is green 100% of the time, and then just as important, make sure you’re provisioning those boxes you know, ready for a build team the minute that they’re proficient, making sure you get passwords out of custom settings, make sure you get data in there, you know, either using the dataloader.io or whatever ETL tools, and get into a bigger organisation that might have that buy-in already. You definitely need to have an organisation that has the buy-in for DevOps, yeah.
Ben: Okay, and you’re going to Dreamforce this year, your first year.
Adam: I am. My first Dreamforce.
Ben: You’re doing a presentation?
Adam: I’m doing a presentation on DevOps, so yeah, I’ll post out the link once my profiles up, if you’re in San Francisco I’d love for you to attend.
Ben: Yeah, well I’ll definitely be there, and thanks for your time today, and definitely recommend anyone that’s going to Dreamforce this year makes it to Adam’s session. I really appreciate that and let’s see how things continue to grow in the DevOps space.
Adam: Thanks Ben.