Top Tech Trends

Share with

Transcript

Starting reasonably soon.

Just over a minute or just under a minute, in fact, now.

So welcome aboard.

Just waiting for the last few folks to, to drop into the session today.

So just before we start, we have the, both the chat and the q and a available on on today's session. So feel free to drop your questions for the panel in there. There'll be a mixture of, questions that we can put to the panel and questions that we can answer in the chat. We have our team available picking up the questions for me while, while I'm moderating.

But, don't be afraid to drop your notes in there, and we shall be kept starting in about thirty seconds.

Alrighty. So I make that just on time now, so we shall get started. So welcome, everybody.

We have our top tech trends in Salesforce DevOps webinar today. I'm Rob Cowell. I'm one of the DevOps advocates here at Gearset, and I look forward to introducing our fantastic panel that we've lined up to talk about some of the the trends that we see in Salesforce DevOps both now and going into next year. So without further ado, I shall introduce oh, I shall I shall learn how to use the slides. Without further ado, I shall introduce our panel.

So firstly, we have David Reid. So David is a principal technical member of staff at Salesforce.

He has a wealth of experience in the nonprofit space, particularly, and is deeply involved in the Cumulus CI DevOps product, within that space, and brings considerable architectural knowledge and and DevOps knowledge, to the table.

Alongside David, we also have Jason Glantz. Jason is currently at MuseLab, but is in fact also a a salesforce dot org alumni, and is also deeply invested in Cumulus CI. I believe he was deeply involved in the creation of said product. So can definitely bring a lot of knowledge to the table on that aspect of Salesforce DevOps.

Last but not least, we have Mitch Mitch Spano from Google.

If you haven't heard of Google, I suggest you Google that one. Mitch is on the Salesforce application engineering team at Google. He's recently presented at Dreamforce on how Google does their Salesforce DevOps. It's a enlightening session. I encourage you to seek out the recordings.

But tonight, that's our panel lineup, and I shall encourage our illustrious panel to switch on their cameras now, and we shall get started. Thank you, everybody.

We're just waiting for Mitch to reappear.

Can't turn on my camera. There we go.

Oh, technical glitches. Okay. Well, we we can hear you, Mitch. So that's that's always a good sign.

I think we're good.

Okay. Perfect.

A a webinar is never a webinar without a few technical bumps along the road.

So there we are. There we are. Okay. So we have the audio. We have the video. We're good to go.

So I guess the kind of headline question that we have, for tonight's session or today's session, depending on your time zone, is what is the direction that we see Salesforce DevOps going for the tech industry? And I appreciate, you know, all of you are in, very much in the tech space, you know, Google being the household name, Salesforce being the industry name, and and certainly sort of creeping into the household name. So from the the perspective of the tech sector and those that use Salesforce within that space, what are the trends that we're starting to see within Salesforce DevOps? I'll start with David on this one.

Sure. I think what I what I am seeing and also what I'm hoping to continue seeing over the next year is a convergence, not of tools, but of practices and ideas between the Salesforce ecosystem and other tech ecosystems around the world. And that that means bringing into Salesforce ideas like, reproducible builds, environments that you get fully configured at a single click. Like, think about the way that her our our our beloved Heroku, for example, gives you review apps, to bring fully configured environments throughout your your development process to support you in moving fast and testing things effectively. And the same thing is is available from, from services like Netlify for people who are building off the Salesforce platform.

Bringing that kind of idea into Salesforce, bringing in, the use of versioned artifacts in the form of packaging.

Those ideas come from all other ecosystems throughout the tech world. They're applicable to Salesforce, but in ways that are really unique to the Salesforce platform and bring, bring value to Salesforce practitioners that, that echoes what we see in other ecosystems, but also has a Salesforce specific twist. Those are those are some of the things that I really see growing within the ecosystem as new tools and processes come online. And and people seem to really be responding to those capabilities and, and the value that they can bring to the Salesforce development process.

No. That's a good that's a great point in the you know, we we do sort of want to start seeing some of the best practice that we've seen on other stacks coming across to Salesforce. And sometimes there's a perception that that that slightly lags behind, in the Salesforce space because of the unique nature of the platform.

So I wanna I wanna kind of push that over to to Mitch now. Obviously, Mitch, you know, you're, you know, probably one of the biggest Salesforce customers. So you're kind of seeing things from the other side of the fence. But, also, I think, you know, Google as an organization, by virtue of its both its scale and, you know, the various industries that it in, probably has quite a a mature DevOps on other platforms. How are you seeing that kind of reflected down into the the Salesforce world?

Yeah. That's a that's a great question.

As you kind of alluded to, Google does have very mature engineering operation practices for all other technology stacks.

The developer workflow is is really incredible. You basically make a change. You get somebody to approve it. You commit it to the repository, and then you walk away and it magically appears within prod about a week later.

So there's a lot of really cool stuff that, that we have access to with when we're writing applications that compile to binary and can run on a local machine and you have semantic versioning and easy rollbacks and feature flags. There's a lot of great stuff that I think that, a lot of folks in Salesforce ecosystem are kind of opening their eyes to and saying, hey. Wait. How can I build some of that into Salesforce development pipelines? So a lot of things like packaging, you know, ephemeral created environments for, building and demonstrations.

A lot of those, I think, are are things that, at least we as a team are trying to enable internally, And I think that as a Salesforce ecosystem, a lot of folks are trying to tackle these same problems together.

Absolutely. And, Jason, you've obviously, got a illustrious background of being sort of closer to the engineering side of Salesforce DevOps and actually sort of building out some of the tools that that deliver on that promise. Where do you see some of the the items that that Mitchell has discussed around, you know, those best practices and and techniques from other platforms slowly creeping into Salesforce? Is that is that something that you you envisage is achievable?

I hope so. I know that that's, you know, when I started at Salesforce nine years ago and was tasked with figuring out DevOps for ISV style development for the products that we were building at Salesforce dot org.

I came from a background as a Python developer with a lot of involvement in open source Python projects. And what I tried to recreate, which sort of eventually became Cumulus CI or kind of what is Cumulus CI today, was really recreating that experience that existed in these open source web projects a decade ago, and were commonplace. And, so I think you know and and and back then, there was very, very few in the Salesforce ecosystem that were familiar with Git and GitHub and using version control even at all. And so I think there was a lot of catch up to be done.

What I see in the coming years, is kind of a couple of areas. I think there is taking, you know, one of the main one of the main best practices in the industry, overall is infrastructure as code, where you're defining everything needed to completely stand up an instance of your application. So you can stand up an instance, run a test, and destroy all of that infrastructure. So you're fully testing every time, you run a build.

I think that those concepts apply really well to Salesforce, especially around the use of Scratch Orgs, which are a great environment to kind of test out infrastructure as code type things.

But I also think that we're starting you know, David alluded to this a little bit about kind of coalescing around some common practices and common, tools and efforts instead of everybody rolling their own and figuring this stuff out on their own.

And I think that that sets us up as a as a community and as an ecosystem to really start discovering the positives of Salesforce DevOps, you know, the things that we can do in the Salesforce DevOps world that you can't do in other projects.

And I think the one of the big ones of that is around ISB style development. There's a lot built into the platform around building packages and delivering complete kind of configured experiences into orgs.

And I see that as you know, rather than kind of being on the defensive about DevOps and Salesforce, I actually think that there are some really positive arguments about how Salesforce is sort of able to set the trend that exists in other cloud based, multi tenant enterprise applications.

You know, these very configuration driven configuration as code type applications.

No. Absolutely. It is you know, in in almost every aspect of the platform, whether it's, you know, the the creation of of the change and and the creation of, you know, valuable, automation and and beyond, or whether that's actually in the delivery phase. You know, you can see innovation based on the the unique quirks that we've all come to love about Salesforce, you know, as that moves across the pipeline.

So as we do move across that pipeline, how do you see security being a consideration in that? You know, we hear a lot in across all dev ops stacks around sort of DevSecOps now, and and the the whole kind of notion of shifting security left, I. E. Shifting it earlier in that process and that pipeline. So do you see more of that sort of evolving as as DevOps matures on the platform? And I shall start with Mitch on that one.

Yeah. There's actually a lot of great things that you can do to increase the trust and, and confidence that you have that the proposed modifications that you're making to your Salesforce application are safe and secure when you have a robust, you know, a strong DevOps pipeline. So a lot of folks may be familiar, for example, the the kind of lowest hanging easiest easiest to digest example of this is that a lot of folks may be familiar with the Apex PMD plug in that you get with Visual Studio Code. So you're writing some some Apex, and if you have an unused local variable, you'll get a little yellow squiggly line underneath it.

Right? For example, within a DevOps pipeline, though, you can take tools, command line tools like PMD, like ESLint, like Prettier, and actually run those as a a pre we call that what a a pre submit job. So, basically, like a hook that gets created whenever a pull request is initiated in your repository. You can automatically scan the contents of your proposed changes and flag any, robotically identified, security vulnerabilities or, you know, errors that you have in your code.

And that that just gives, it just decreases a lot of the responsibility, from the individual developers and the senior engineer who might be taking a look at and performing code review and puts it really on the shoulder of the robot. The the robot's kind of the bad guy, but the robot's really a good guy in the sense that it's protecting the integrity of the the sensitive data within your Salesforce application itself. So, you know, you know, PMD, ESLint, you know, even something silly like Prettier just to to check the the validity of the formatting of your code. All of these are things that that, we can use as an example and build upon to make sure that as part of your check-in process, you're automatically having the robot to determine if you're introducing any security security vulnerabilities or not.

So, as your engineering, organization gets more and more mature, something like this is actually, like, kind of a prerequisite. It's it's it it it almost becomes impossible to scale without it, as your, the scope of the code base increases.

Absolutely. Yeah. And I've I've definitely seen Salesforce kind of ramping up that effort. So I I recently went to a a a Trailblazer community group, with in London with Salesforce, where they were presenting on the new sort of or or the enhancements to the code analyzer tool that Salesforce provides, which is a fantastic tool that encompasses a lot of those things that you've talked about, you know, with PMD and ESLint and basically analyzing your code and preempting problems, not just in the security space but, you know, across the board. And that's interesting in that it's a tool that originally was targeted at the you know, very much more at this sort of the ISV packaging space, but is now matured to a point where it's actually useful to, Salesforce admins and developers across the board.

So, Jason, I know that, you know, your your heart still somewhat belongs to the the ISV and the and the packaging space. So what what are your kind of insights, shall I say, on the security as a as a factor of building out those packages?

Yeah. I think well, I I guess one, sort of clarification I'll give is, I I, I had had a whole slide on this in my session that I did at at DevOps Dream in in Seattle, about sort of what is ISV style development. When I talk about I I I and I kind of mentioned it as ISV style because I do think that, it is a style of development that is applicable to a lot of Salesforce customers, especially big enterprise organizations.

The more you go through a digital transformation and bring more departments on board, the more their demand there's going to be for each of those departments to have more autonomy over their contributions to the overall org configuration.

But I I I think, you know, when we think about overall trends, I mentioned, you know, that that when I started in the Salesforce world, Git was was very rarely used and wasn't a common skill set that you find, in in developers, in the ecosystem.

I think that that has changed a lot. I think there are a lot more people that are using Git in some way as part of their Salesforce DevOps pipeline.

The challenge is, I think there's still a whole bunch of stuff that we don't have represented in Git, and that goes back to this notion of infrastructure as code, where, for instance, in in, you know, in in the ISV space, it's quite common for an ISV to, have all their package source and version control. But then they do all their testing in a persistent org where there's a bunch of manual changes. Or when they deliver trials to customers, they're doing it through a trial for a source org. It's just a persistent org that somebody logs into and makes the manual changes instead of it being and and so none of that is represented in version control.

And I think that that represents a real challenge from a security standpoint because all of these awesome tools that are coming out from a security standpoint are based around the idea that you've got files in version control that could be scanned and and run through a pipeline. So if you have things about what you need to deliver what you're building that are not in version control, where version control is really then version control is really not your source of truth, and you need it to be the source of truth to have those, security aspects. The second point on that is, getting everything into version control also allows you to use all of the built in compliance machinery and all of the git hosts that are out there, whether it's GitLab, Bitbucket, you you know, GitHub, to do things like make sure that there's code reviews before a merge can happen or there's passing builds and the tests are passing, to restrict who can who has access to the keys to the path to production, so that you essentially create a wall so that a developer cannot directly release into production, that there's some review of that process overall.

And but all of that to me is centered around version control. So I really hope, as far as trends, that's a trend that we start seeing broader adoption of is really having version control be a complete source of truth.

Absolutely. And and the the the notion of source con source of truth is is is always a contentious one in these these types of, discussions. You know, some folks, you know, in a very much in a sort of, you know, an enterprise setting, for example, might contend that the production org is always the source of truth. Because until it's in the hands of your end users that are using it, they can't see it. It's not a truth for them. But I think we'll we'll save that for discussion for another day because I think we could get very deep into the weeds of of the the definition of source of truth.

So it it's interesting that you talk about, you know, some of the things that we we could be doing, particularly around that sort of, you know, that notion of infrastructure as code. One of the other interesting things that I've I've kind of seen ramp up over the last year or two, and this is kind of slightly downstream of of DevOps, it's more of the development stage, is the increased use of AI.

We see, you know, get a a plugin that helps you sort of autocomplete code. The folks over at tab nine have have something similar. You know, we're now seeing over the last sort of few days, people using, a chatbot to to generate code snippets, which I've, you know, I followed on social media today and found absolutely astounding.

So what what other sort of cutting edge stuff are you seeing sort of mature teams in the tech space doing with their their Salesforce, with their DevOps? And I'll I'll put that one to to to David initially.

Sure.

Well, maybe I could touch on AI briefly first.

I'm a I'm a bit of an AI skeptic, to be honest. Although I've I've played with chat TPT as along everyone alongside everyone else on Twitter and been both excited and horrified by by what I've seen.

I I'm very skeptical about the notion that AI will produce a sea change in how we do work, whether that's DevOps or security.

What I the great promise that I see there in that space is as an aid to skilled operators, a velocity enhancement to people who are already doing very high quality work on the platform.

I don't think it's a real opportunity for us to reduce the skill floor that we demand of our engineers, of our operators in various roles, but it can make the people who are already doing great work more effective.

But in terms of in terms of DevOps practices that are that are being put to great use across the ecosystem, what I see as the the most critical focus shift that people make is moving away from the idea that DevOps is a thing that one does in a relatively narrow space. Right? It's something that happens after an engineer does some work, and then it's over and it moves forward to production. Right? And DevOps engagement is sort of that space between an engineer and production.

The way I like to think about it is, and I'll I'll pull back a phrase that you used a moment ago, Rob, shifting left.

This which which highlights this notion that the pipeline between creation of value and delivery of value starts a lot earlier and ends a lot later than that narrow vision of DevOps. And DevOps can deliver value across this much broader pipeline that starts from products design with declarative users like PMs, and it doesn't actually end at delivery. It ends at maintenance and support. It ends at, the far end of your customer journey, and not as they as they start realizing value, but as they continue realizing value over the five years that they're using your application. But, like, whether you're an ISV or an end user.

If you expand your thinking in that way, there are opportunities to take DevOps and grow it across that that whole breadth of the application life cycle. And when you do that, it starts to unlock value in, workflows that are not otherwise impacted by DevOps at organizations that practice this much more narrow vision.

And when that happens, I what I what I start to see and I hope other folks see who are practicing this kind of operation is that, DevOps is no longer a cost center. It's a value generator for many, many people, many different stakeholders across your the application life cycle, not just for engineers.

No. That's that's absolutely right. And I think, you know thank you, David, for the the the timely reminder that, you know, we shouldn't forget that DevOps isn't just dev. It's also ops. You know, it's that day to day BAU keeping the wheels turning aspect that sometimes gets overlooked.

So with that in mind, Mitch, obviously, you're like I said, you're you're sort of more on sort of the the end user, side of the fence. You, you know, you you you're part of a business that that has a a day job that isn't necessarily, all engineering.

So in terms of those kind of day to day fixes and those operational challenges, you know, what are the the challenges, that you as a Salesforce team face within that industry, within that org?

Yeah. There's a there are quite a few. The number one thing that I wish that we could do that's really challenging to do as an end customer is like we alluded to before, create that ephemeral environment purely from source that matches exactly what your production org looks like. That's that's particularly challenged to challenging to do in the Salesforce ecosystem right now with the current set of tools that are available.

There are some really, really promising technologies that are coming to maturity. Those mostly being Scratch Works and second generation packaging, which will help you to partition your otherwise monolithic force app, application into smaller discrete chunks that have explicitly defined dependencies and then have a repeatable build path that'll say install these dependence install these packages in the order defined in the dependency tree. That is something that is quite challenging to do as a customer particularly when you have, you know, third party packages. Right?

So you might have a survey vendor. You might have, you know, all of you might have something like field trips, some sort of utility packages.

Being able to create out of out of the command line, basically, an environment that looks and feels just like your production org, is quite quite tough. But I I do think that there's a, like you said, there's a tremendous value. It's It's not just a cost. It's a value driver, David had said that, in the sense that your business systems analysts or, your product owners can just spin up an environment, give a demonstration of what's possible with what your team has currently built, and share that with other other folks very, very easily and get them interested and, you know, kind of open their eyes to the capabilities that Salesforce has to offer and how it's tailored to your specific business. Those things are really, really, really great, and there's a lot of opportunity in that space, particularly for us as an end customer. And another thing that's kind of kind of, unique about us is that Google is a huge organization.

So for us, as we, adopt these technologies and kind of, you know, discover these best practices, we're gonna be able to take some of these things that would have traditionally need to be needed to be done in every bespoke Salesforce org across the entire enterprise. We're gonna be able to create reusable packages with shared team ownership that can be installed plug and play into any any Salesforce org within the enterprise. Right? So so common things like a logging framework, an HTTP callout framework, a a trigger handler framework. All of these things, they they kind of only need to be solved once, and that's that's really, really appealing for a large customer such as ourselves with many bespoke Salesforce orgs. You can get a lot of value from, cross team collaboration in a way that just simply was not possible on Salesforce about five years ago.

I love that that notion of a, like, a plug and play API economy where you can actually kind of have, I guess, something akin to sort of off the shelf parts to solve those particular business needs and have that sort of core baseline of, well, you know, any given implementation is gonna need to have security. It's gonna need to have this. It's gonna have need to have that, you know, and kinda get that framework built out.

You talked about, you know, a lot of, you know, the build part of that, you know, sort of being sort of command line and and scripts and that. And I I I do wonder sometimes whether, you know, that scares folks off some of the Salesforce DevOps best practice.

You know, certainly in the the dev end of DevOps, you know, we see an increased drive towards low code tools. We see, you know, configuration over over code.

Do we think that that will be a trend for for the DevOps space? I'm gonna put that one to JSON to simulate because I know you you continue to be close to, making DevOps more accessible to to folks and and kind of working on some of those problem areas. So, Jason, what do you see in terms of making DevOps more accessible, to to get those best practices in?

Yeah. It's a great question. So we it was I I I I look. Looking back and reflecting on my time at Salesforce dot org, I think a lot of the innovation that we had was due to different happy accidents. Like, just kind of the parameters of the world that we were working in sort of led to this kind of innovation.

One of the big ones of those is that we had open source managed package products. So we have the, you know, nonprofit success pack that was built or that's the core of nonprofit cloud that is built still today in a public open source GitHub repository.

And so we had this added requirement that we wanted to support this whole community of nonprofits where, say, a food bank wants to get together and, you know, food bank doesn't compete with a food bank and the county next door to them. They wanna feed more people. So if they built a solution, they want to share it. And there's an inherent desire to share that's, I think exists in the Salesforce ecosystem. It's even more so in the Salesforce dot org ecosystem.

The problem is, you know, everybody knows how to go into an org and build solutions. What they don't know how to do is turn that into something that's that can be delivered in a repeatable and scalable way.

And so, you know, we spent a lot of years trying to solve that problem. There's a an amazing program in salesforce dot org, Commons. It used to be called the Open Source Commons, that actually runs community sprints to try to foster these sort of community driven projects where somebody from the nonprofit and or people from the nonprofit and education ecosystem get together to kind of build some common solution or some niche solution for particular, you know, pet adoption solution or food banks or or things like that.

And what I've found from working in that community, especially, was, and it was actually, Kevin Forman, who pointed this out to me, many years ago, that all the tools that we had built were great, but they intimidated even him as kind of one of the leading DevOps experts. This was seven, eight years ago, back when Cumulus AI was Ant based. And, he pointed out that, his partner, is an amazing Salesforce consultant, but at the declarative side. And it would be amazing to figure out how do we engage her and minds like her to build solutions for the nonprofit space.

And, you know, now that's called the citizen developer. You know, in a lot of ways is is kind of the, you know, the buzzword around that. I think that it's huge, and I think that it opens up and it really brings the power of the Salesforce platform that I was talking about earlier and how DevOps can actually be an advantage for Salesforce as opposed to something that we're trying to play defense on, as a community. And, yeah, the I think part of that is Mitch used a word in in his response, partition your org, which I have generally thought of as as modularizing.

But I like the word partition because it is really about walling off a particular part of your org.

And, and when you do that, you're actually creating a smaller problem space. You know, for instance, if you just wanna have your HR functionality developed, it is much easier to automate everything that's necessary to stand up just the HR functionality of your, larger org and have that automated through a repository where you can make that automation accessible, not just on the command line, but with, you know, web based tooling. I know, part of Qumulo Suite was, Mateko. Got a t shirt on for that.

And, Meta Deploy, both web tools that allow you to run the automation from Qumulo CI through a web interface in order to spin up, orgs or configure an org or install a product that doesn't just install the product but actually, you know, creates the community, configures it, and does all of that extra, for you. The the last way that I'll I'll I'll say is I actually do believe that there is a misconception, that exists in the community that you have to learn to if you're an admin, you have to learn to be a developer in order to learn DevOps. And that is I I absolutely do not believe that, to be true.

Learning to code is learning all the logic, all the syntax, all sorts of weird stuff that can be very tricky, and I'm still on that journey twenty years into it. The and David's seen some of my codes. I'm sure he's chuckling, but, but I I I think it really is a a skill set that is, I think, much more approachable to admins than we kind of give it credit for, as an ecosystem. And I know that that's something that I'm really passionate about is is trying to encourage more admins to to take the plunge into that world and and and not view the barrier to getting there as the same barrier as learning to code in Apex and write LWC and and all of that.

That's that's a way more difficult challenge, I I believe, than understanding DevOps.

So do you think we should go sorry. Go on, Mitch. Go ahead.

Sorry. I I I just wanna piggyback off of Jason's comment there. Just a strong plus one that if you're a system admin, your idea of interacting with the DevOps pipeline might seem very scary, you know, as scary as compiling a hello world program or something like that. In reality, it's it's not not anything like that.

You only need to know about a handful of git commands. And then, also, if you have a strong partnership with your engineers, your engineers can expose tooling to make it such that you really don't even need to know those git commands. For example, if you were to let's just assume that you have a small org and everything works fine in a in a scratch org for your primary build environment. Right?

You can then go into that scratch org and you can, you know, you can specify which components you want bundled into, say, like, a a package, like, go into the setup menu and create a package, and then have your command line tool read from that package. So So that way the admins are used to using those point and click user interfaces like they have been throughout their entire career, and their stuff can get easily into the pipeline without having to learn any command line tools whatsoever. So if there's a strong partnership between, I think that that's what really actually makes a great Salesforce DevOps engineer is keeping the admins in mind as well as just as well as the developers.

Actually, I would probably say admins first, because then you can create tooling that really does decrease the barrier to interacting with the git repository, interacting with your automated tooling, interacting with your build scripts, all of that stuff. It it becomes, you know, a matter of clicks instead of a matter of, oh my gosh. I need to learn all these git commands. I need to know what's going on.

I need to have Visual Studio Code installed, all this stuff. I think, Jason, you had mentioned Mateo. Mateo is an incredible tool. I think it's, I saw a demo of it.

It was blown away, about a year and a half ago. There are awesome tools that we as developers can produce that will decrease the barrier to entry for our, admin partners.

Absolutely.

If I can add on Sure.

Sure. Go ahead.

I'm sorry, Robbie. I I'm jumping all over the the moderator here, But I just I wanted to I wanted to reemphasize that the vision Mitch articulated of an an org where where any stakeholder, admin or otherwise, can get access to a fully configured environment that lets them do their work, whether that's building with clicks, building with code, doing a demo, offering training, whatever.

When you build for that vision as part of your DevOps practice, that's the hard part.

Exposing it in a in a clicks not code way to other stakeholders, that's comparatively the easy part.

When you and when you make that that critical shift to, to create you know, end to end automation that can build those ephemeral environments to serve the needs of your users, it becomes, again, something that you can put a really clear value on to bring that to all of the stakeholders, including including declarative admins.

So at that point, to me, it's an easy sell to say, you know what? We're gonna have a developer spend an hour putting together a a point and click job in GitHub actions or Jenkins or a bespoke tool that that brings this to another audience because we've demonstrated the value that audiences all throughout our application process can get from from what we've created.

Absolutely. And I think, you know, there's there's definitely a a bit of a perception problem going on with with DevOps and, you know, short of renaming it to something that doesn't have the word dev in front of it. So we we do have, some questions from our from our audience today, and I think, we we definitely have one that that touches and extends on that a little bit. So, John in the chat is asking, what could be driving the misconception that admins need to have a developer skill set to practice DevOps and version control? And I guess off the back of that, I'd probably sort of extend it to to say, what can we do about it? How can we how can we change that perception?

So, Jason, do you wanna have a initial stab at that one?

Sure. I I think you sort of hinted at this, to begin with. We call it DevOps.

That inherently sounds unapproachable to someone that's not a developer. The irony is that a lot of DevOps teams in the Salesforce world are really just operations teams. There's not really a whole lot of development about the deployment process going on. It's just, you know, manual operations to kinda transfer things between works and and such.

I I really do think that, you know, one of the things that we did, with the, Salesforce dot org commons, program is we added on when we would do a two day sprint, we added on an extra half day.

That was a session that I got to lead, guiding a room of mostly admins, mostly declarative developers through, setting up their system, through creating their first Git repository, creating a feature branch, creating a scratch org, capturing changes, you know, kind of the whole development workflow of what it looks like to do that sort of stuff. But with with them just running a handful of commands and then doing everything declaratively in an org and then capturing it. And I think once people get that first experience, and and, you know, there there's something really powerful about that experience of of knowing that you can do it.

I know, one of the projects that we spent a lot of time on was the building applications with Cumulus or build applications with CumulusCI, Trail on Trailhead that was really written, with the intent of being approachable to admins, but not condescending to devs, and trying to find that right sweet spot. And I I do think a lot of the documentation in in the DevOps space in particular is so heavily dev oriented, that it it becomes really tricky.

The the other thing is I think it's it's it's better tools, you know, and continuing to improve, tools, improve the user experience of tools. A lot of times when we think about user experience, we think of a web application, point and click and everything, but a command line has a user experience too. Some of the things coming forward in the new SFCLI, are I I think it'd be some really significant enhancements of that command line user experience, making commands more common, instead of having to remember a bunch of option flags and and things like that that just make it more approachable to, new users.

Fantastic. And and, hopefully, that's, that's answered, some of the the the points that, John was raising there. I'd love to open that question up to to all of you. However, I do have one last question that I think is an absolute killer question, and we can just squeeze it in at the last minute. So very quickly, Harold Meyer has asked, what is your take on Salesforce DevOps centers?

Can you interpret it as Change Sets two point o, or can you see it moving towards actually bringing some of those best practices of development and DevOps into, the ecosystem?

I'm gonna get Mitch's take on this as a as a Salesforce outsider, as in not employed or formally employed by Salesforce, and then perhaps we'll we'll throw it over to, to David. So, Mitch.

Sure. That's, that's a great question. The Salesforce DevOps Center has been a very promising product for a few years. We've all kind of been really excited to hear about its, its, development process, and we're excited that it's it's generally available now.

Unfortunately, the only supported, back end right now is GitHub. So our team is kind of out of luck in that space. We can't use GitHub for any of our, Git repositories. So it's it's off limits for us, but we have done some initial investigation, and I think that it does solve a lot of the challenges that a lot of folks had, had brought up particularly for the admins.

In my opinion, if you have a strong DevOps pipeline, the the only thing that's really missing from the admin's perspective is how do I build an environment that I can that actually has all the stuff in it, which we've kind of talked about. And then once I've built that environment and made some changes, how do I take those changes and get them back into the rest of the project? And that's where I think that Salesforce DevOps center really, really does decrease the barrier to entry because it has the ability to extract all of the metadata that the that the admin has most recently touched, create a pull request, all of those things where you you know, I said it earlier, you need to know a hand line of commit handful of command line, commands.

The DevOps center actually knows those commands on your behalf. So it really decreases that that barrier to entry. And like I said, great DevOps engineers start with the admins in mind, and I think that the folks at Salesforce have done a tremendous job at that.

I'm I'm really interested to see how that's going to proliferate across other Git providers, Bitbucket, GitLab, GitLab. For us, you know, it's not not very commonly used, but there's a there's a Git provider called Garrett, which is a, provided by Google. It's an open source Git, Git protocol, encode review tool. So we're really excited to see how that can proliferate across the ecosystem.

It's a very promising tool. And, for us as for us as customers, and for a lot of folks where the ad there are a lot of strong admins, I think that it's going to be an absolute game changer in terms of their operational maturity, getting the admins to interact with the repository and then all of the build, of all of the automated security quality build steps that that can accompany the, you know, the the triggered that are triggered on the invocation of a pull request. All all of those great things, they just get for free as soon as they can check their stuff from their build environment into the repository or propose that code change.

So I'm really excited to see what the future has in store for the Salesforce DevOps center.

Fantastic. My apologies, David. We are somewhat over time now. So, unfortunately, I can't get the official Salesforce line on DevOps center.

Although I I know that Salesforce are very transparent with their road map. You can you can look that up online and and see the direction of intent, shall we say, that the DevOps center product will take. But, hopefully, that gives some some perspective on that. With that, as I say, we we are a fraction over time.

So all it remains for me to do is to thank our three panelists, David, Jason, and Mitch. Hopefully, everyone's got some great value out of that.

I do see that we have some more questions coming in there, but we are unfortunately out of time. But do feel free to contact us. You can reach us at team at gearset dot com with any DevOps related questions you may have on there. And with that, I shall allow folks to head off and continue their day. Thank you very much, everybody, and we'll speak again soon.

Thank you.