Description
Catch up on this webinar with Gearset’s Co-Founders, Kevin Boyle and Matt Dickens, as they explore how Salesforce’s DevOps Center tool will look, and how it might benefit Salesforce admins and developers. They cover:
- Why was Salesforce DevOps Center needed?
- Salesforce DevOps Center versus Salesforce DX
- What is Salesforce DevOps Center?
- The benefits and challenges of Salesforce DevOps Center.
Learn more:
Transcript
Fantastic. Thank you, Ben. Okay. Well, I guess we'll start with some intros. So, hey, folks.
I'm Matt for those of you who don't know me. As Ben said, I'm a cofounder at Gisa. I'm also chief product officer here. So I'm a software developer by background originally.
I've been a professional software developer for nearly fifteen years now. I started out in video games then quickly moved into product, to develop productivity tools, where the hours were a little bit more favorable. And, I've spent the last sort of ten years in DevOps, specifically. I've been responsible for building some big parts of Gearset early on, and then more recently, obviously, I've been focusing on setting Gearset's product direction.
Hi, everybody. I'm Kevin. I'm the CEO here at Gearset. And like Matt, I'm a developer by background. I don't love that Matt's pointed out that it's fifteen years, but I was doing the sums of my head. I I think I'm the same. I built lots of Gearset's original platform and technology alongside Matt and a few of the other folks that started with us, And I've ended up knowing far more about the Salesforce metadata API than I ever planned on knowing or or really truthfully want to know.
Good stuff. So the plan today is basically to pull together everything that we found and learned so far about DevOps Center and just share that with you folks. We've tried to sort of look far and wide for everything we can, from around the web, and from other sources too, and we've then delved into some of the detail to see what we can infer about what's happening behind the scenes as well. As been said, feel free to leave questions in the little box as we go. I'm gonna I'm gonna break rank here and, change the plan a little bit, and I I think we'll save the q and a for the end if that's okay just so we can, keep things flowing smoothly.
Great stuff. Well, to fully understand why Salesforce are creating DevOps center, I think an understanding of the wider context is necessary and and how DevOps on the Salesforce platform has evolved over time.
And it really has been an evolution.
Do you wanna knock the slide there? There. Great. And it it really has been an evolution.
So, obviously, now we all know that Salesforce is the premier enterprise application platform as a service, but, you know, that wasn't always the case. As many of you are no doubt aware, Salesforce started out life as a CRM application category defining one, but, you know, it it was a much simpler, much simpler offering.
There are many reasons, behind the success of Salesforce and the CRM marketplace, but, certainly, the extent of the customization was was a key factor and a key differentiator, how how easily you could make those changes. You no longer had to wait around for your CRM supplier to implement the change you needed, or get the workflow changes to align with how your business ran. The application can be molded to what you needed.
As Salesforce grew in success, so did the complexity and degree of customization that the customers were making.
The first major way I think that Salesforce started to enable teams of folks customizing the platform was via the Salesforce metadata API.
So it provides a very course, very rough way to externalize those customizations, that have been made and export and import those, through, you know, a flow of sandboxes.
The metadata API, though, was amazing and and led to an initial wave of things like Maven's Mate, the Eclipse IDE, or, you know, basic wrappers around the metadata API like the AMP tool.
This spurred a whole wave of innovation on the platform.
Folks can do more complex things. The platform offering from Salesforce itself, broadened significantly.
And you now have large teams doing really complex things, and that's led to products like Gearset, Capato, Otterrabbit, and and the other DevOps vendors. And, you know, we're helping all those teams, manage their DevOps processes.
All those vendors were allowing teams to adopt industry recognized practices like source control, continuous integration.
And Salesforce spotted that vendors were often having to jump through hoops to get the metadata API to play nicely, reinventing the wheel, and we were also slightly diverging from each other a little. So Salesforce came up with Salesforce DX, and that was a plan to provide a unified set of primitives and a base experience that the community and vendors, could build on top of.
So when Salesforce announced Salesforce DX, it was around a vision of getting all customers to move away from the org as a source of truth and adopt the source control system as the way to collaborate. This I'm sure you've all heard this phrase a million times of, you know, source control is a source of truth, but Salesforce DX was the first step on that path.
Salesforce DX is a is a technical solution for a technical audience.
Using Git and the Salesforce CLI has a steep learning curve, particularly if you're unfamiliar using command line tools already. You know, there's there's there's quite a lot of learning to do there. It's proven popular with hardcore devs, teams with a very strong technical bent, or devs coming from other platforms where, you know, that way of workings, much more much more than done thing.
But I think it's fair to say that adoption of DX hasn't been widespread, and that's primarily due to that learning curve.
You know, think about a team with processes built around the Salesforce CLI and and Salesforce DX.
It's not uncommon to see siloing starting to occur.
You have the programmatic developers on the team using Visual Studio Code and the Salesforce CLI to work with Git, and, you know, it works really well for those guys.
You then have admins and declarative developers, and they're often left relying on, you know, the programmatic devs to migrate their changes or use an entirely different workflow because who wants to be beholden to your colleague, to share changes with the rest of your team?
And what this often means is that a lot of declarative changes aren't captured by source control, which subverts the DevOps process and erodes the value of adopting these tools and practices in in the first place. You need to find a way to get everybody on the team committing their changes to source control.
So if there's a spectrum of developer, you know, from programmatic developer through to the cloud of developer, and everybody in between, obviously. You know, Salesforce DX targets the programmatic end, and DevOps center takes over where DX leaves off.
And given the cloud of developers and admins a way to take part in source control is a big thing, compared with where we are today where a lot of folks still, you know, are forced to use Chinesets.
And I I think one of the reasons that Chinesets is so popular is because a lot of Salesforce customers start off without, you know, that vision of what their complex DevOps challenges are gonna be. Obviously, enterprise customers adopting Salesforce as a platform really different. They can foresee that coming complexity. But for many customers, it's something that creeps on upon them over time.
So for many, life starts with change sets. It's frustrating to use. I don't think that's very controversial, but, you know, it gets the job done to a certain degree. It's built in. It's from the first party, and it's free.
Unfortunately, change sets, you know, lead you to a dead end, and it it encourage you to invest time and energy in learning a process and toolset that will inevitably run out of road when the complexity of your org and the team and the challenge outgrows chain sets. And it really is an inevitability for almost all customers.
And when that happens, you need to reset your expectations, and learn a totally different way of working.
So DevOps center is the is the next phase in Salesforce's vision of having Git the the way to collaborate on the platform, whether you're declarative developer or a programmatic developer.
It's a built in way of adopting source control on day one even before you have the complexity that, you know, source control is is well suited to address so that when your complexity increases and you need to work with other industry standard tools or increase the diversity of folks on your team, you've already got a big history and a big investment in your source control system already, and that will act as the primary integration point.
K. Cool. Thanks, Kevin. So we've heard a bit about why DevOps center is useful and where it's been where it's come from and then how it fits in alongside DX. Next, let's take a bit of a look at what it will actually do on day one and then where we think it's likely to head based on things that we've read and heard and so on.
So following on from what Kevin said about siloing, the idea is that DevOps center bridges that gap between programmatic and declarative developers. So the vision is that this new UI driven companion to DX will let programmatic and declarative developers and admins all manage all of their changes through Git, delivering on that vision of externalizing the source of truth for your org. So to begin with, it's gonna cover the section that we've highlighted in this diagram here. So taking changes made in the sandbox and then committing them to Git.
But looking further out, we think it's likely to go quite a bit further than that, and we'll talk about that a little more a little bit better. Ultimately, though, the goal is obviously to get more Salesforce teams adopting source driven development and DevOps practices, and then, obviously, that lets them make changes more regularly and more reliably and get more value out of the platform as well and all that good stuff. And as Kevin mentioned, there's now an expectation of these sorts of tools amongst development teams given the proliferation of DevOps practices and tools on other platforms as well.
So let's have a look at how it actually works then. So as I said, we've pulled a lot of this stuff from around the web and things that are publicly available. We're also on an internal pilot, which we've been playing with a bit, so we've got a little bit of insight from there too. And then there are a few things that we've pulled from things like, TDX and, publicly available FAQ.
What we've tried to do is dig into some of those details that give us a little bit of a better understanding of what's going on behind the scenes as well. So firstly, DevOps center will be delivered as a managed package. That's gonna be something that you install preferably into a dev hub org. So that's that's definitely the intent.
And then once DevOps center is installed and it's up and running, you'll find that its workflow is built, pretty much completely around projects and work items. So projects are a container for your work items, and they have a one to one mapping with an associated Git repo.
It's likely that DevOps center will support all of the usual Git providers that you'd expect, like GitHub and GitLab and Bitbucket and so on. But we know that the first one available at launch is likely to be GitHub.
So then within projects, you have a series of work items, and I'm sure most of you, if not all of you actually know, what these work items or user stories are given the ubiquity of tools like Jira and so on. But just in case, work items describe the kind of tasks and deliverables that your team are gonna be working on in a kind of nice fine granular way.
So if you open up one of these work items, you'll notice that they're fairly lightweight compared to what you see in the likes of Jira. So there's a subject and a description. Those are the user configurable parts.
But like I say, we're expecting to see integration with popular third party tools here. So Jira and Agile Accelerator are the ones that we've seen mentioned publicly so far.
When creating a work item, you'll then pick a sandbox to associate with it. So this is gonna be the dev environment that you'll be making changes in, and these changes will then be associated and tracked with, the work item that that sandbox is attached to. You'll be able to connect any number of sandboxes and scratch orgs to DevOps center. I think it'll work in a similar way to gear set where once you're logged into your, your DevOps center kind of hub org, you'll then be able to authorize various other sandboxes and scratch orgs and so on from there. And then, once you've done that, you can assign each of those to different work items.
You can see in the screenshot above then that there's a source field on this work item that references dev s p four, and that's the sandbox that's associated with that particular work item. The other thing you'll notice then is that there's also a destination field on there which points at a git branch. So I mentioned earlier that every project has a one to one mapping with a git repo, but every work item has a one to one mapping with a git branch as well within that repository. So when you start work on a work item, DevOps center will go ahead and spin up that branch behind the scenes, for you.
So then the next step is you click on launch dev environment in the top right, and that bounces you out to the associated sandbox where you can start making those changes.
Not gonna dive into making changes now. I'm sure you all know how to make changes to a Salesforce org. But once you've made those changes, you'll be able to then associate them with that work item in actually quite a neat way. So DevOps center relies on the source tracking stuff that if any of you have been playing the scratch orgs or or even playing with the source tracking, stuff in the, in sandboxes that's in beta at the moment, then you'll be familiar with it.
But you'll notice that pull changes button in the bottom left. If you click that pull changes button, it will populate your work item with all of the metadata changes that you've made in your sandbox. So I haven't actually tried source tracking in the last couple months. But looking at the metadata coverage report that Salesforce publishes, it looks like it's pretty much got complete parity with the metadata API these days.
So it's really unlikely that you'll accidentally miss changes that it hasn't detected or something like that. So that that looks really cool. Once you've done that, you can then stage which changes you want to commit to that associated branch or, more specifically, you can exclude changes that you don't want to, stage by clicking that little ignore button. Once you've done that, you can then add commit comments and hit submit changes, and that will commit the changes associated with this work item to the associated git branch.
And, obviously, you can go through that cycle multiple times so you can make some small changes. You can go and fetch those changes and commit them, and then make some more changes, fetch those changes and commit them, and so on.
Behind the scenes, that'll run a each time you go through that commit process, it'll run a git checkout a git checkout, a git add, a git commit, and a git push to make sure that all those changes are then committed to your branch and synced back to GitHub, but you haven't had to issue a single git command by hand yourself, which is nice.
I don't have a screenshot of the next bit, unfortunately.
I'm just borrowing things that I could find publicly to be safe. But, I know that when you then mark this stage as completed and move the ticket to in review, then DevOps center will automatically create a poll request between that work item branch and master in that project repo in GitHub.
And this has been a little bit short and sweet, this section, but that's everything that we can expect to see in the initial release as far as we're aware. So, obviously, there's some overlap here in terms of, well, I guess, gear set and DevOps center solving parts of the same problem, And I don't wanna come across as as you see these big red crosses on the screen here, I don't wanna come across as some biased or cynical tools vendor criticizing the competition.
Like, honestly, I think what we've seen at DevOps center so far is is actually really, really cool, and I know that there's a team of fantastic people working on it. Some of those people we know really well, but I think it's still useful to talk about some of the things that are missing at the moment. So the first omission, from my perspective is deployment to orgs. So at the moment, everything in dev ops center and everything you saw there, is around pulling changes from orgs to get repos. And that's really helpful if you're already set up with DevOps tools, on your wider team because then DevOps center can hand off to your version control system, and those changes can flow through your usual release process and out into production from there.
It does mean though that this isn't then an immediate drop in replacement for something like change sets because there's currently no built in mechanism to push your changes back out to an org.
So secondly, obviously, if there's no deployments and no way to push those changes out to an org, then there's no built in CI yet. So I'd fully expect to see a more complete pipeline model somewhere down the line with changes moving from dev to QA to UAT and out to release, or from within the UI. As an early step, I wouldn't be surprised to see Salesforce demoing DevOps center used in conjunction with DX and Heroku pipelines or something similar in the future, just because we've seen, demos of DX and pipelines in in the past. But as things stand, if you want an end to end DevOps process, then you'll need to set that up elsewhere.
Thirdly, although you can choose which top level items you want to commit, there's no fine grain control over which changes you wanna commit. So if you've made I think profiles are always a good example here, but if you've made multiple changes to the same profile, let's say you've added a couple custom fields, to a a custom objects and then you've you've added some permissions to, profile to go along with those as well, and then you wanna only include one of those fields in the commit, then you're out of luck when it comes to the actual permissions to go along with it because the only option is to commit the whole profile or none of it at all.
And then, I guess alongside this, there's there's no built in comparison. Obviously, I would say that as a as someone who works at GIS, where comparison is one of the things that we do quite nicely, but you can fetch the changes and and and pick which ones you want to include and exclude, but you can't review what's changed before committing it to your branch. So that does run the risk of accidentally including things that you didn't necessarily intend to. Those are the kind of the four main things that I wanted to call out. Obviously, there are other things that DevOps center isn't really expected to tackle, so I I don't expect it to solve things like data deployments, for instance. But these things here are things that I think would make sense as features inside DevOps center, somewhere down the line, but at the moment, they're currently absent.
So I just to give you a bit of an idea of what I think we can expect to see sort of sooner rather than later, I I know I've touched on most of these already, but just to summarize, I'm I'm pretty confident we'll see deployments from branches to orgs very soon, because without that kind of part of the puzzle, it's, it's a little bit limited.
Secondly, it looks like the team that are working on this, they don't really wanna reinvent the wheel, from from what we've seen so far anyway. And DevOps center doesn't seem designed to replace all of your existing DevOps tools, but rather kind of fill in some of those gaps. So this means we'd expect to see lots and lots of integrations with the sorts of tools that round out your DevOps process, particularly with those popular source control providers, ALM tools, CI tools, and so on.
That being said, we've got a pretty good hunch that we'll see some sort of built in CI functionality at some point. Some point. Like I said, likely based on Heroku pipelines. I remember back at the announcement of DX, which I think was around four years ago now. I was checking this out the the other day. We had a brief glimpse of Heroku powered CI for Salesforce, so it wouldn't be surprising if that's the direction that, that we see this go at some point, but that one's a little bit up in the air. I guess we could be we could be wrong there.
Okay. So that's actually everything we have about the features of DevOps center that we know about right now.
But let's take a look at what they actually buy us today. So so firstly, I think the, the work items and feature branches combo is really nice. Obviously, work items are great because they keep the work that you're doing focused on, sort of particular well defined and well scoped deliverable, and then it provides a way to group changes that you've made into a single concept that you can then progress through your, release workflow.
And if you're using a Git workflow already based on feature branches as your branching strategy, then you're in really good hands. That's it's essentially the, branching strategy that, DevOps center seems to assume to begin with, and enforcing that one repo per project and one branch per work item is a really nice way to keep, a lot of the, a lot of the complexity of Git at bay.
And then I I guess I'd say that DevOps center seems like a really promising start at solving this bigger problem of accessibility and collaboration. So it definitely does go some way to, breaking down those walls between those silos.
I guess if part of your team is already working from source control and it has a DevOps process in place, like I already said, or if there's part of your team that's responsible for trying to introduce a DevOps process, alongside DevOps center, then DevOps center really does open that up to the wider team, in a way that, you know, it's it's kinda hard to fill, with with some of the, well, existing first party tools today for sure. And then it also has this other kind of side benefit of letting declarative developers and admins take advantage of some of those key features of source control that aren't necessarily that accessible right now. So, obviously, it's a really easy way to share changes you've made with your colleagues via the source control system. And then it also lets you introduce peer review into your development process, which is something that, we quite often see as kind of lacking in the in in the Salesforce ecosystem.
So going through a few of the challenges now and some of the limitations, I think it probably warrants saying DevOps center isn't even out yet. So, of course, there's gonna be limitations to these early versions, and it it'll be unfair on Karen and the the team at Salesforce if we focused on any of that. You know, I'm not gonna focus any specific tactical missing feature. Instead, I'm gonna look at a few of the different themes that may me that may make taking part at source control difficult even when there's a built in way to do that.
The first theme I think that's worth calling out is that, you know, great DevOps isn't simply tooling. You know, you get the best tooling in the world and still struggle with this stuff.
DevOps is the coming together of tools, processes, and people.
Now, of course, having great tools can make the process and people side a lot easier, but you do need all of these things aligned.
So if you look at DevOps center, you know, it's it's clear that the work item is is a key, unit there that we're building on top of. And having good granularity there seems to be a key way of of how the tool works. And that means that it's vital to have well defined small isolated tasks.
And that's that's a tricky thing and and requires practice, so it it won't happen overnight. It's it's definitely a good place to get to. It's a it's a key tenant tenant of good agile development, but it's it's tricky if if you're not working that way.
When you factor in that many teams still have a single release window, you know, once per sprint, that means you can be building up, you know, a couple of weeks or a month worth of work between releases.
In that time, conflicts can occur can occur, and that really happy path that we've shown at DevOps center may start to struggle or it's a little bit unclear how that's all gonna hang together.
It's also unclear where DevOps center will support branching strategies that are more complex than the feature branching model. So feature branching, by the way, is a is a great way to work. We actively encourage it. But there are a bunch of folks that reach a level of complexity where that model will start to fall apart. And, you know, a big part of what Matt and I do for our customers is work with them to understand, you know, based on their team, based on their workflows, what branching strategy works for them. You know, you need to find ways where you create feature branches from a specific branch or an environment branch, finding ways to merge branches together, hotfix branches, and, you know, there's a bunch of complexity there.
And, of course, pushing the source control is is only the start. As as Matt touched on, there's a a missing part of the puzzle, which is deploying changes from source control to an org, and and, obviously, this will this will come in time.
And when you think about pushing changes from source control to an org, you know, that that's not just useful downstream in your deployment process when you come to deploy to production.
Even the act of starting work in a sandbox usually involves first syncing any changes from your feature branch into your sandbox to give you that clean starting point to make your changes on top of. And it sounds like a fairly straightforward proposition to push changes from a branch to an org. I mean, it's it's just the reverse of what it's already doing. But as someone that spent five years building tools on top of the metadata API to solve that exact problem, there's actually a there's a bunch of complexity and and thorniness there that that's not super easy to overcome.
It'll be really interesting to see how DevOps center caters for some of those problems.
A bunch of the challenges where, you know, you you can't just overwrite the metadata in the target org. You have to be respectful of of what's already in there.
A key way that, DevOps centers looks set to work is you're gonna need to work in an isolated sandbox. So no more working in shared sandboxes.
Well, you know, that that's a good thing, but it begs the question, how do I spin up a sandbox that's well configured, looks like my feature branch? Scratch orgs can be an assist here, but it's far from a solved problem and it comes back to that, you know, pushing changes from the branch into the org and getting that all up to scratch that I mentioned a few moments ago.
Once you have your own sandbox to work in, life is good. There's this realization that we're never working on these things alone. You know, we've we've got a team around us. So how will we share changes, amongst my colleagues on a team working on, you know, their isolated sandbox? Maybe they're at the same feature branch. Maybe they're not. Maybe there's some interdependencies between those things.
And finally, metadata is is one part of the puzzle, but how does the sandbox get get enough data to be useful for testing? And to be really clear, like, all of these are tractable problems, and they they can all be solved and addressed over time. But I think there's gonna be some change management with the way the teams work today and and bringing in some of these practices.
And we we actually have this problem as well at Gearset. You know? With I think with all DevOps tooling, there's a tension. How much of the underlying complexity of Git source control branching and and CI should be exposed to the user?
So if you think about something like the Salesforce CLI, you can see how everything works, but that creates the steep learning curve. DevOps center seeks to hide that complexity, which is good, but I think we won't know until you try it out for real if the balance is right there. So, you know, to to really make this concrete, consider this scenario. You know, user stories and work items, they tend to have a one to one mapping for the states they can be in. You know, they do to do dev, UAT, production.
But branches that underlying currency of the source control system don't don't share that, mapping. So think about what happens when a story fails to pass UAT and gets pulled out before release. You know, what state should your branches be left in? Should the feature branch be reverted?
Should you do, like, a reverse hotfix? Should you just create a new user story to fix the thing before you ship? There's a there's a whole bunch of, you know, sort of thorny problems to fix, fix, and Git can be fiddly. So what do you do when these things inevitably go wrong?
I think you're probably still gonna need to have a Git ninja or two in your team, you know, for this some of this stuff to work really well.
Okay. Cool. Thanks, Kevin. So just to summarize really quickly then, obviously, we think that DX has solved a decent part of that DevOps puzzle, but it's certainly not the solution for everyone from what we've seen. And that means at best, there's siloing, and at worst, there are teams that can't adopt source control and DevOps practices at all yet.
And and, obviously, DevOps center is then intended to address that problem. So to begin with, this is all about making changes in your org and then moving them into a Git repo without having to get familiar with all that Git tooling. And but crucially, you'll be able to kind of work, with source control straight out of the box without having to pick up any third party tools. And, obviously, the vision going forward is to create that, that real kind of UI counterpart to DX that'll let you control a lot of the same things that you can control with DX and build out a lot of, similar functionality, but in a UI, instead of of with the CLI and and, you know, bespoke, CI tools and things like that.
So I've included some of the resources here that, we we use that obviously, a great source is is the chatter group that you can join so you can keep a bit of an idea of of kind of what's or keep keep your finger on the pulse, I suppose. Other good resources, there's a good presentation at TDX that has a pretty complete workflow video of some of the things that we've just shown. So if you watch that, you you can hear someone better at demoing it than me doing it in real time, which is which is pretty great. There's a a blog post on the admin blog that, that really highlights some of the the the benefits specifically for admins here.
And then there's an FAQ in Quip that has some of, some extra detail, talking about things like, pricing models, for instance. So I think at at at the moment, the expectation is there'll be a free tier and a paid tier. And there are a couple of other extra, like, tiny details in there that, that you might be interested in.
I guess just following on from what Kevin said, though, I'm kinda gonna finish with a bit of a plug here, somewhat shamelessly, but not forget at the product. You may be surprised to hear. So, obviously, Kevin mentioned that tools are kind of part of the problem, but we've definitely seen that, like, process and education are part of the problem too. We found that there's a lot of pent up demand for learning materials around DevOps concepts that are specifically tailored towards the Salesforce ecosystem.
You know, there's a ton of stuff out there about branching, in the general case and, how you can build together CI pipelines using kind of, popular tools and open source tools and things like that. But there's actually not nearly as much about how you can do some of this stuff specifically with Salesforce. And, obviously, there's a lot of overlap, but there are some kind of, edge cases and some some differences too. So what we've tried to do is put together a learning resource, DevOps Launchpad.
We're trying to keep it completely vendor agnostic, so you won't see it covered in gear set branding or anything like that. But we're trying to provide a whole variety of learning materials about all things DevOps for Salesforce. We've put a few courses up already about Git and branching primarily, and there's also a course on how to use gear set, but that's the only reference to gear set you'll see there, I promise. And we're also trying to source completely independent content from around the ecosystem as well and lots more topics that will kind of fall under this, DevOps banner.
We've got a few lined up. So I wish I could talk about them publicly now, but I should probably wait until they're actually in there and live before, before I name names. It's completely free, so feel free to sign up and run through some of the courses if you're interested in learning more about Salesforce DevOps. And, obviously, please send your feedback our way.
It's, it's only been live for about a week, I think. For those of you who are GearSet users, you've probably already seen the little rocket icon in the GearSet UI that will bounce you straight out to it. But we're we're really keen to hear, all of the feedback and particularly topics that you'd really like to hear spoken about. Like like I say, we're we're we're making a big effort here to kind of reach out to the wider community and pull in people who are experts in their fields to talk about topics that are kinda close to their heart.
So hopefully, it'll prove to be a really useful, resource for teams who are adopting Dev ops on Salesforce.
And I think that's everything.
So We've actually had a few questions come in, Matt.
I have answered five typed. So this is gonna be a fun game where I'm gonna ask you the same question and see if your answer is different from mine.
No. No. No. Don't play this. I don't like this game. You've answered the questions.
I don't This is a fun game.
So DevOps so the first question, comes from Hong Basu, and the question is, so DevOps center would be a native Salesforce app like Capato. So a work item is equal to a user story.
Right. That was a clarification on that side. Exactly.
Yes. That's absolutely true. So it'll be a a a managed package that you install, and I'm assuming that there will be, objects that will get created that represent work items inside, your, Salesforce instance. And, yeah, those work items are user stories.
Great stuff. And the only other thing that I added to my kite answer was I think I think this would be publicly announced that or you could imagine a future, where there'd be integration for things like Jira or Agile Accelerator and, you know, wouldn't be a million miles away from belief that would be possible.
No. You're right. That that I think that's been publicly announced. That's that's referenced in the FAQ. So, I think Jira and Agile Accelerator are the two that I mentioned there.
Great. Has there been any mention of integration with Microsoft Azure products such as Azure DevOps?
That's a good question. Not that I've seen so far. But, to be honest, it's getting to the point where I kinda consider Azure DevOps to be, like, one of those main Git hosting providers now. So from from, like, a Git hosting perspective, I wouldn't be surprised to see it. From a, work item, like, ALM perspective, I guess I I don't know. But, like, honestly, I I haven't seen anything so far.
Great. And I would just add that, you should check out the chatter group and go directly to, Karen and the team for that. You know, even if they don't support it or if it's not on a publicly announced road map, I suspect, like, we're product as ourselves. We love getting feedback on gear set. I suspect they'll want feedback on what integrations you wanna see.
Yeah. I'm sure they will.
Is DevOps center focused only on unmanaged development, or does it support ISVs developing managed packages as well? And that question's from Ian McDonald.
Good question. So I think, basically, everything we've seen so far, looks to be focused on unmanaged development. That's I I I guess I can't really elaborate because I haven't seen anything to the contrary. So my guess is that, like, packaging has to feature into this somewhere down the line. It's just not something that that I've seen any mention of so far.
Yep. Somebody wants to know which county in Ireland I'm from, which I suspect is a a family member, a distant family member perhaps.
With Salesforce DevOps in place, here's a great question for you, Matt. With Salesforce DevOps in place, is it so with the Salesforce DevOps center in place, is it a possible replacement for Gearset, or does it add value to Gearset?
That's a good question.
Kevin actually answered this. I asked Kevin this question earlier because I was like, someone's gonna ask us this question, Kevin. So what what would you say? And he gave a really eloquent answer, and now I'm gonna give a much a much worse answer that you can then fill in the gaps for.
I'm kind of I I guess as as, I guess, a cofounder, I'm I'm viewing this in the same way that, that I view DX really, which is that anything that that pushes, DevOps on the platform is gonna be beneficial for anyone using the platform and and even for tools vendors like like like us building on top of the platform. So I think, I guess in one way of thinking about it is that, I guess further down the line when we see DevOps center kinda more fleshed out and feature rich, what I expect to see is that it will essentially be, be something that helps lead people partway down the path to, you know, to adopting version control, to starting pick up some of these DevOps best practices.
But then there'll be a point of complexity where a tool like Gearset can be, particularly helpful. I think there are there are definitely things that, we're not gonna see, get added to DevOps center in the foreseeable future, where Gaze that can add quite a lot of value. And the other thing I'd expect to see is that there will be integration points. So at the moment, obviously, the main integration point is the source control system, but I I would fully expect that going forwards, we'll we'll find ways to work more closely with, the folks working on this.
Like I said, we've got pretty good relationships with, Wade and Karen, and we tend to try and stay in touch with them as as best we can to make sure that we're not kind of working on solving the same problems as each other. It's just kind of vital, I suppose, as a a third party and a first party ecosystem to pay really close attention, try and stay close to the changes that that the and the innovations that the first party are making, and and that's what we try to do. So, I don't see the ops center replacing gear set or, or eroding you to the tier of gear set, but I do see it, helping further the case for DevOps on the Salesforce platform, which I think is a really great thing.
Yeah. I guess Matt and I have spent a pretty significant fraction of our careers now trying to get Salesforce teams to use source control. This has been a really interesting validation on this thing that we've been shouting about and trying to enable. And for us, getting more folks using source control from day one, is is only a good thing.
Alright. These are now all the questions that I I haven't answered.
So Okay.
Well, I mean, your answers were so useful already.
So Is the commit all or nothing?
So Daniel, asks, is the commit all or nothing at the metadata level, or do they have the ability to pick and choose specific changes in a single metadata record?
Okay. That's a good question. So, at the so I haven't dug into this in as much detail as I would like, so I'll share what I what I've what I think I've seen so far. So my guess is that behind the scenes, it's using the, the source representation of the metadata, which means that I'd imagine if you're making changes to custom fields, and things like that, like parts of custom objects, then the granularity is probably at the the the field level.
But if you're making changes to things like profiles or other large types that have lots of components, then I think at the moment, the granularity is at the, is at the level of of that top level type. So that means that there will be cases where you can pick the fine grain things that you wanna push in there, then there'll be cases that you still can't. Yeah. That's what I've seen so far.
Anything to add, Kevin?
No. Nothing. From the publicly available stuff, it looks like it's basically using the SFDX stuff under the hood. So expect to see a level of granularity as an SFDX file. So if that's a custom field or, you know, the custom object record, but whatever it is, it'll be that file level of granularity is my is my expectation.
I guess I'd expect that that having this tool out there in the wild will drive a lot of that sort of feedback about breaking up more of the complex types. So shameless plug for Gearset. One of the things that Gearset did right from the start before even DX did it was break apart lots of complex types, so splitting out custom fields and things like that. But we also do that sort of thing with profiles and so on. Because, again, we've had that feedback over a really long time, and we didn't have the capacity to go and change the way the metadata API works or anything like that. So we we we kind of had to do it on the other side ourselves. But we imagine, like, as soon as this is out in the wild, people gonna start making those sorts of requests as well.
So, you know, I I wouldn't be surprised if it if it ended up on their backlog.
Nice easy question from Chris.
Do you know if DevOps center plans to be a paid feature or a free feature or a mix?
Okay. Good question. So the only bit of info I've seen about that so far is in the quick FAQ, and that says there will be free and paid tiers, and it doesn't elaborate on what those tiers will be or how much they will cost.
So Hundgren's got a a good question around git and branch strategies. So does DevOps center support promotion or release branches?
Again, good question. Not that I've seen so far. So at at the moment, the the operations that I've seen DevOps center do behind the scenes are, create a branch for you from master.
So when you've created your project, you associate a, a repository with it. And then when you create a new work item, it will create a branch from that. Then when you move that work item into, ready for review, it'll create a pull request from that branch that it created back onto the branch that it created it from, which is you usually master. It might always be master, actually. I I haven't checked. But I haven't seen anything that shows it letting you choose targets for mergers or things like that.
Will there be support for non metadata data? And then for some examples are, like, product price book entries and the other CPQ stuff.
So, again, what I've seen so far is that that doesn't appear to be, the case from day one. My guess is that would be further down the road map. I think deploy I I I kinda wish we could just get, some of those folks on here to to do this webinar as well just so they could get more concrete answers. My guess about their road map, knowing about how we built Gearset's road map, was that there there are probably, metadata centric problems that are quite hard to fix first. And then once you get through some of those, sort of harder metadata centric ones, then approaching, stuff that's configured via data is is almost like a completely separate set of problems. So my my guess is that if you do see that, it'll be quite far down the line. But, again, I I do not work at Salesforce, so I'm just making guesses here.
There's a question about gear set specifically, so I'm gonna skip that one. But the person that asked that, which data centers we run-in, if you wanna just email me, gavin at gear set dot com, then I suspect I've got some good news for you. But I'm gonna skip it because it's not DevOps center related.
Fair enough.
Joey asks, do you have any recommended resources or books to explore the best practices on our branching strategies like the dev hotfix, etcetera? Where can I learn?
Cool. Perfect. Well, I would recommend you sign up for DevOps Launchpad. If you go to DevOps Launchpad dot com, you can sign up in, like, just one click or, and you don't need to give us any information.
Just log in with your email address and stuff. And there are already, I think, three Git based courses there. Two or three. One is, basically, an introduction to Git.
So I think there are two. One is an introduction to Git, and then the second one is basically going through the branching strategies in detail.
That said, if you want if you have specific questions and you wanna jump on a call, I spend probably half of every day on calls talking about branching strategies and and listening to people talk about, what problems they're facing internally. So I'm really, really happy, like, no obligation, you know, to buy anything or anything like that. If if you wanna just ask questions about branching strategies or if if if there's anything you wanna learn, then feel free just to shoot me an email at matt, m a t t, at gyrsett dot com, and I'll be more than happy to jump on a call with you.
Yeah. It goes back to that tension around sort of showing the complexity of the branch and strategy and kind of for us at GearSat. You know, we put a lot of engineering and r and d into getting that balance right.
So talking to customers about the branch and strategy is is sort of key to our element.
So if anybody's in the control and wants some support there, we'll selfishly learn from you at the same time.
Yeah. That's it. I I I very deliberately ask, basically, anyone in the team, whether it's, customer success or, or sales or any anyone. If they're talking to a user that has, like, interesting branching problems, then I wanna be on that call because it just means that it gives us an opportunity to find ways to make Giselle better handle those really interesting scenarios. So, I'm really sad, and it's a really fun topic for me.
So Here's a question to Tiguan of Fremont.
Is connecting to GitHub dev ops center just as seamless and easy as what I've experienced with the years at?
That's a good question. In a known biased way.
That's a good question. I'm I'm gonna be really nice and say, yeah, it's it's it's not it's not dissimilar. So, I mean, it'll still be, like, using the OAuth flow and things like that. It it won't be a case of, like, handing over your credentials, those sorts of things. So I I I'd expect that to be very similar, but slightly less good because because I have to I have to have a slight bias.
It's a QSAT webinar. So Yeah.
Is it true that Salesforce DX is a better fit for ISVs that are developing managed apps for all orgs compared with, you know, typical instance customization moving from dev to end to production?
That's a really good question. It's definitely true that I see, like, heavy DX usage way more commonly, amongst those ISV partners, I guess, for a few reasons. One is that they normally have lots of in house technical expertise, probably like more more like, deeper and richer technical expertise than than, lots of other Salesforce teams. It it it doesn't mean that, you know, folks doing customizations towards that have deep technical resources too. It's just on the average on on average, I see a lot more of that in ISVs.
And that tends to mean that challenge there is not this you know, you think of the shape of a Salesforce team that's optimizing for the business.
You need a bunch of business experts that can collaborate and understand and and translate those business requirements. Whereas ISV teams, again, broad generalization, but ISV teams tend to be your more classic software engineering teams building a software engineering product, and you don't really have quite so many of the business or domain experts on there. Again, broad generalizations, but slightly different mix of folks.
Yeah. It's true. And then the other aspect of it, I suppose, is just, by virtue of the value of packaging to those types of, Salesforce developers versus, folks doing customizations to their own orgs, basically, they I I guess ISVs go a lot more heavily into packaging than we see pretty much anywhere else.
And, obviously, with things like unlock packages, that's quite an appealing, that's quite an appealing way to start managing some of that complexity for those sort of, more sophisticated teams that are already relying on packaging mechanisms anyway. So it feels like it kind of pulls them into DX a lot more, and then they start to see a lot more value in it. And they're also better set up to, to kind of tackle some of those learning curves and technical challenges alongside it. So so, yeah, I I I see it more commonly. Whether it's better or not, I I I think it's just, it's probably more practical to use for those types of teams, but it doesn't mean that that there isn't value in in DX for, for those in house teams as well.
Yeah. I I completely agree. I think one interesting thing with DevOps center is gonna be that bridge as we talked about between declarative devs and programmatic devs where you'll probably you know, DevOps center will also yield the adoption of Salesforce DX for a whole bunch of folks as well. So it's it's next and complimentary.
Chris would like to know, do you see Gearset adopting similar functionality that DevOps center is utilizing things like putting changes with source tracking, versus selecting metadata types combined with the benefits that Gearset has, you know, that diff viewer and that workflow?
That's a really sensible question. And, just so you know, we're we're we're probably gonna start hiring for product managers soon. So, like, a slight slight joke there, but, but I I I I think that's a really good question. It's definitely that I've been thinking about a lot more recently.
I think the way that Gearsett works at the moment solves, kind of a a broader set of problems, but then it definitely falls short for places that already want to buy heavily into using those work items and have that bound to what's going on in tools like GearSet. So I definitely think there's a sweet spot that's probably somewhere between what we do today and somewhere that adopts slightly more of the sorts of things that DevOps center started out with, that might be able to bring us the benefits of both. So no forward looking statements or anything like that, but I think, you know, there there might be some sort of interesting work to do there and some interesting sweet spot.
Yeah. It's a good observation.
Good stuff. Can I deploy specific components using my package XML?
Well, that's a good question.
Well, I guess the thing at the moment is there's no there's no deployment via DevOps center from the Git repo back out to an org. So I haven't so so kind of the package XML is almost out of the picture there to some degree.
I I hope that answers your question. Kevin, anything else you can add or elaborate?
No. I think you're totally right. I I think, again, going back to SFDX, so the package XML has been fairly relegated as a as a I know it's still supported, but as a it's it's not sort of at least, I understand it's just not key. You shouldn't really use that as part of the SFDX workflow. So my Yeah.
That won't that that probably isn't high on the road map, but, again, the chat or group would be a good good place to go and ask that and get the answer direct from from And and, again, if if that's the thing that you're interested in talking about more, I'm I'm kinda curious as to the use case there, just because I I think package XML like, over time, as a lot of the fundamentals get more straightforward, like, things like source tracking get better and we start using CI more heavily, then I think the value of the package XML is like an arbiter of what gets deployed and the definition of a deployment package.
That gets eroded, and it becomes, if if anything, most useful for, like, a a project definition or or something like that. Obviously, in GIS, we have things like metadata filters where you describe the types of metadata that you're interested in, the types that you want. Then you can, like, filter by package XML and things like that. It it it kind of starts to describe the scope of the work that you're actually interested in in general rather than the work that's associated with a specific item that you're applying, if if that makes sense.
Our our friend Mark Burrow wants to know, is that a platinum record behind me? He didn't know I was a singer.
If you knew me well, you would know I'm a massive Springsteen fan, and that was a gift from my my wife that, is a barn to run a cold record.
I I would have been on it if I had known Bruce earlier.
James would like to know the best resource aside from, DevOps Launchpad for establishing a CICD workflow with Gear Set and GitHub actions, with a large consideration of enablement for a non techie admins. So where can James go to learn about that kind of topic if it isn't, DevOps Launchpad?
That's a really good question. I I did think after I plugged that Launchpad that I probably should have been a bit more agnostic there as well and and listen to a few other places. But what you've asked is actually that feels quite complex to me, and I I wish I had a better answer than, you know, that there isn't, like, a single source that can give you a a really good idea of that other than the Gearset docs and then talking to us as well.
But, like, there's there's docs dot Gearset dot com, which covers a lot of the Gearset side of that. But I think what to be honest, you've highlighted the thing that we don't do as well as we could, really.
What we do is like, gear Gearset is designed to facilitate lots of different types of workflows. When we're talking about different branching strategies and things like that, you can build pretty much all of them out using Gearset. But what we don't do is have really good, strong opinionated guides on, so you want to adopt this workflow. This is exactly how you set it up in Gearset. At the moment, that's still a little bit more of a kind of concierge process where, you know, you'll get one of the team on a call, and and we'll walk you through those steps. So you've you've kind of highlighted a bit of a gap there. If if if you're keen to piece some of this together yourself, then I'd rely on things like docs dot gear set dot com and DevOps Launchpad and, obviously, reaching out to the gear set team, via Snapchat or, obviously, email me, matt at gear set dot com again.
That's probably the the, unfortunately, the best way I think to go about it right now. Kevin, anything else?
Nope. I think I think you're spot on there.
And then it's a gap that we sorry. Go on.
Oh, go ahead.
No. I was just gonna say it's a gap that we know exists in terms of documentation, making it really easy to self-service that kind of stuff. So it's, it's something we're aware of.
Yeah. James has actually followed up with the chat, said he'd love to chat more.
Okay. Great.
So definitely, James, get in touch. I was saying that, I think, no fun at cocktail parties. We end up talking up and and not chatting about it. So get in touch with him. Again, we'll we'll give you advice on how you would do this with gear set, but we'll also just chat to you about how you would do it with Jenkins or GitHub actions or whatever whatever it is, whatever your poison is. Yeah.
And then final question, Matt. Will DevOps center support package deployment? So I think that's, a second generation packaging is is how I'm interpreting that.
Yep. Good question again.
What I've seen immediately, no. So, again, from what I've seen in in the tool right now, it's not gonna be there. Going further out, I can't imagine that it wouldn't be on the road map given, given how heavily, Salesforce have pushed, those those second generation packages. So I I'd expect to see it down down the line.
Gustav, that's that's all the questions. So, yeah, thank you very much, everybody that attended.
I'd say that we'll send out an email afterwards with the resources to that chatter group. It'd be a great place to go and ask questions and give feedback to the DevOps center folks directly. We love, say, speaking to people. So if you do have any questions for me and Matt, any feedback, thoughts, or you just wanna have a chat, then feel free to reach out.
I'm kevin at gearset dot com. Matt is matt at gearset dot com. And if you have any feedback after trying DevOps Launchpad as well, that's our newest thing that just launched. They would love some feedback on that.
But you get an email afterwards with the recording. It has been an absolute pleasure, chatting and answering some of your questions. So thank you very much for attending.
Thanks so much, folks. It's been a pleasure.
