Visualizing your Salesforce releases

Share with

Description

Catch up on this session recording from the Gearset DevOps Summit 2021 with Karen Fidelak, Senior Director of Product Management at Salesforce, and Matt Dickens, CPO and Co-Founder of Gearset. They discuss the benefits of giving your whole team visibility into your releases including streamlining collaboration, moving away from Change Sets, and where Salesforce DevOps is heading.

Learn more:

Related videos

Transcript

So I hope everyone has a chance to, grab a quick cup of tea or a drink there in that break, and we are gonna get ready for our next session. And that is Karen Firdalak and Matt Dickens who are going to be having a fireside chat to discuss the importance of visualizing your release pipelines.

Now if we have time at the end of this, we will be running another q and a at the end of this session. So, again, if you do want to pose any questions to Karen or Matt, please do post them in the chat during their session.

Karen, Matt, welcome to the summit today. I hope you can hear me alright, and I will hand over to you.

Cool. Thank you so much, Jason. And do we have Karen? We do. Karen, good to see you again.

How are you doing?

Good.

Good.

I'm I'm alright. Thank you. Cool. So, I guess first, we should probably kick off with some intros. I don't really think you need an introduction, but you wanna go first anyway?

Sure. I'm Karen Podellic. I'm a product manager here at Salesforce. I, I'm I'm a I'm on our platform team working on our developer services set of functionality around our developer experience. I've been with Salesforce now for, about four and a half years working on our platform team that whole time. And right now, I'm responsible for our DevOps solutions that we're working on.

Perfect. Awesome. Thank you. And, obviously, Jason's introduced me, but just just in case, Liz, you don't know me, I'm Matt.

I'm, one of Gessler's cofounders and chief product officer, and my background's really in software engineering. So I've been a professional software engineer for probably about fifteen years or so now, and I'd say the bulk of that I've spent in the kind of DevOps space in in one form or another and, obviously, more recently in Salesforce DevOps. So, with intros out of the way, I suppose to get us started, hopefully, folks joining us have already seen what we're doing with pipelines and gear set because Ollie just did his fantastic demo. Thank you, Ollie.

But I guess, Karen, you haven't had a chance to demo DevOps center today.

So for people who aren't familiar, could you give us a quick overview of what it is?

Yes. Yes. So we're working on a product that we're calling DevOps center.

We're basically trying to deliver a full end to end solution that takes users through a change and release management process, using modern capabilities like source control. We're building this basically on top of our kind of principles and foundation of Salesforce DX.

We're trying to provide an experience that really helps our particularly our low code users and our teams of developers who include low code users, take advantage of modern best practices, around source control, continuous integration and delivery, managing their changes in a in a kind of more sane way than they do today, particularly with, change sets, which is our current alternative that we have today. So we're really excited about, what we're doing and happy to have this conversation with you today.

That's cool. Fighting the DevOps good fight. I I like it. Yeah. So, how far along are you with DevOps center today? What what stage is it at?

Yeah. So we're currently we're running a pilot right now that's been going since about May.

We'll be shifting to a beta later this year, and then our plan right now is to GA.

We're looking at kinda late spring time frame of next year.

So that's where we're at.

And can people jump into the pilot now, or is it best to wait for the beta? Or how does that work?

Yeah. So we're we're enrolling or we're nominating, for the beta right now.

What I would recommend is to contact your AE, your Salesforce AE, if you're interested in getting involved, and we can get you going in that nomination process, to look at enrollment in the beta. We we may be able to throw some more people into the pilot, but the kind of the standard path right now is to is to go into the beta.

Cool. That makes sense. Okay. So I know that when we started building the pipeline stuff in Gear Set, we did a bunch of research, and we had kind of a sort of specific archetypal team in mind. I guess when you guys kicked off DevOps center and as you've been building it out, have you had a specific type of user or team that you've been really focused on?

Yeah. Yeah. So we're kinda focused on two categories right now. One is just that low code user, that declarative user, the admins who really are are change that users today, that just need a a better experience, a more robust experience.

I know you know how awful I've changed that experience is.

I wouldn't describe it that way, but yours, not mine.

Yeah.

So, you know, that's that's, like, our first category.

So just really provide what Salesforce first should be providing is a is a a better experience for declarative users, around change and release management.

And then along with that goes sort of this notion of these hybrid teams. So teams that maybe they have more pro developer, personas who are taking advantage of Salesforce DX goodness, like using source control, using the command line.

But meanwhile, they have these low code users on their team who aren't familiar or comfortable with those those kinds of tools, and they cannot work together today. So we're trying to provide a solution that lets them work together in a unified and consistent way, but using tools, and experiences and interfaces that they're comfortable with.

Makes total sense. I I think we're we're following broadly the the same approach there, I I reckon. I think one thing I can probably add from our perspective is that, I think for us, it was partially motivated by, I I suppose, like, the the journey that we've been on, I suppose. We we originally started out dealing almost exclusively with end users.

So we kind of built a company that that built a product that that would talk to and sell to end users of of the platform. People were just trying to get their stuff done during the day, and they were probably struggling with with change sets at the time or, you know, maybe not enjoying using change sets quite quite so much. And we kind of started out with those folks building a solution for them, but, obviously, those folks then take their products take the products that they're using into their teams, and then the teams start adopting it. And suddenly, you have to start solving these collaboration challenges for teams.

And then the teams get bigger and bigger, and you flash forward a few years, and suddenly, you've got a whole bunch of big enterprise users. So and I think smaller teams tend to have the ability to be a bit more kind of agile in my experience, so they've probably got a little bit more control over their process. They've got a little bit more self determination, the the ability to tweak what they do. But I think what we found is as you get towards those larger teams with diverse technical backgrounds and those kinds of hybrid workflows that you mentioned, we found a whole bunch more process inertia.

And I think we sort of saw pipelines, as a way to kind of help those people with that type of of of process inertia for those kind of larger teams. So, basically, similar to you folks, but definitely motivated by by some of those those those bigger teams. Yeah.

I guess, obviously, DevOps Center's based around the idea of release pipelines. That's why we're here and chatting. How did you come to that conclusion? Was was there a I guess, were there any other approaches that you folks tried, or was it always really obvious that pipelines were the way to go?

Yeah. I would say it was pretty natural for us, like, from the start to to adopt this kind of pipeline, this visual pipeline representation model.

We you know, in a lot of our documentation and marketing collateral that you'll see us talking about the ALM process and DevOps, We always represent it as this left to right process where you've got these multiple stages starting with development, going through multiple stages of testing through different sandbox environments, and then through to a production environment.

So that I think is just a a common mental model for us, particularly when we're trying to educate and and provide guidance around what this process looks like.

So I think that was just sort of the the starting point for us, and it and it felt pretty natural to do that. We also have a bit of a precedent with our Heroku pipelines product, that has that same basic pattern and model. So, you know, we we look to that a bit as well. But I think it's just generally for us, it was it was pretty it was pretty natural.

That makes sense. I I remember one of the early DX announcements and and that being tied into hierarchical pipelines and stuff like that. So the the lineage makes complete sense to me. Exactly.

I guess maybe we've taken, like, a slightly slightly different route almost, I suppose, by virtue of kind of coming in from the outside out outside of the platform. So, obviously, we started building gears up when we started adopting Salesforce, and we found the kind of tools didn't really exist for us. Us. And I think, we kind of lent on that inspiration from from outside of the platform.

So when we first implemented CI, we kind of went straight for this holy grail type use case where, you know, teams should be able to release on demand by anybody on the team. And when you release, you release everything that's ready to go. And it it kind of completely ties in with that elite category in the Dora reports and stuff like that, you know, with the idea being that you you merge changes only when they're ready for release, and then you very rarely pull changes back out from a release. Like, that's might happen very occasionally if there's a show stopping bug, but incredibly rare.

And and you end up with this kind of more lightweight, kind of faster moving process, and that that was how we built GearSet to begin with, and that's how we could ship to prod multiple times a day. And, you know, we have a bunch of GIS at users that work in that way and use GIS at CI like that today. And I think where it's possible, it's really, really good. But then, obviously, there's the kind of inertia stuff that we mentioned where you've got, like, a long approvals process.

Maybe you have to wait a while and business users to come in and sign off on things. Then features get held up at various different environments in the pipeline, and you have to progress features independently around each other. And and that's become a kind of cultural norm, I think, for Salesforce where, you know, deciding that one feature isn't gonna make a release quite late in the day is pretty standard. It's it's kind of just part of what what people do.

But it also means a much more complex process. Right? It means that at each stage, you're not really testing this single cohesive set of features. You're testing this kind of moving set of features where some features make it in and some features maybe get pulled out.

So it just gets a little bit more complicated. And we found that there are lots of teams in the ecosystem that just work that way out of necessity now. It's it's the way that their process has been built up, and it can be really hard to make that kind of change. So companies can't make it overnight, and I don't think teams should try and shift overnight.

You know, like, DevOps is this kind of incremental process. It's it's about incremental adoption and incremental improvement. And I think the way we kinda see pipelines is an incremental improvement to help teams that are facing that kind of inertia challenge again, if that makes any sense.

Anyway Yeah.

No. That resonates for sure. I I was gonna say, like, one of one of our early kind of contentious decisions, and when we were designing this, amongst our own internal team was kind of hitting on exactly some of the stuff you're talking about. This notion of when you're, like, merging from one branch or one stage to the next, are you merging everything that's in that stage? Or are you able to maybe pick and choose or leave things out?

And the traditional Salesforce or the traditional development model, sort of traditional software development model would say, of course, when you merge one branch to the next, you merge everything. And that's how, like, sort of standard developers would think.

As we all know, Salesforce development is is not always what we would consider, like, traditional. Right?

And people have adopted different practices partly because because I would I would blame ourselves on, like, how we've allowed some of this flexibility over over the years of just the the the notion that you can deploy any set of metadata from one environment to another that sort of lends itself to this model that people have adopted, which is just what you said. Like, oh, wait. I'm not ready to to promote everything from this environment to the next one. I, you know, I only wanna promote these three items, or I only wanna I wanna promote everything except this one item.

So, anyways, we we battled a bit internally on this because the the product side was trying to say, like, no. This is a real use case, and customers really need this because that's how they develop on the Salesforce platform. And our developers who aren't necessarily grown up being Salesforce developers, we're like, I don't get it. That doesn't make any sense.

You know? I'm like, but that's that's how they do it. And so we have to build a system that supports that. And so we did.

So we made a decision to basically support kind of both of these models. One where you have this added flexibility where you can kind of pick and choose individually, which work items or sets of changes you wanna move from one stage to the next or as a process where you're moving everything, like all new changes move from one stage to the next.

And we're we're doing that through an ability to customize and configure your pipeline when you set it up to basically define how each stage is going to, what the promotion model is gonna be for each stage in the pipeline. So trying to give everybody, you know, the option to fit within the model that they have internally. So interesting. Yeah.

Yeah. Yeah. It sounds like we came to very similar conclusions. Yeah. I I have to deal with this internally.

I'm I'm both on the product side and on the engineering side. So I have this, like, internal struggle going back and forth. But, I I I think it's important to try and solve the core problem and then steer people towards what we think is best practice as as best we can and just help people on that journey. So, yeah, I I think we're on the same page.

Exactly. Yeah.

I know we've talked about some of the benefits of pipelines already, but are there any are there any other benefits that you folks had in mind when you when you when you started building this stuff out?

Yeah. So, again, sort of something you just hit on. I think we're viewing this as an opportunity to provide a little bit of prescription. So we hear a lot from users that they want us to be more opinionated about what should I do?

Like, how should I set up my pipeline? Like, how many stages should I have? How should I set up my branching strategy? What kinds of sandboxes should I use?

You know, these sorts of questions. And so we are using this tool to help provide some guidance. Like, we're we're guiding people through a setup experience with this that, lets you, you know, set things up in a way that we would recommend, but also balance it with having some flexibility for what people, may need. And that's been a sort of a challenge also is balancing that, you know, being opinionated, and providing guardrails around that, but then also providing enough flexibility, and customization where it's going to be needed, without making it overly complicated for probably the masses that really need just something that's a little bit more, prescribed.

So I think that's one of the benefits we see. Another one is around visualizing and having a better sense of where changes are in the overall life cycle in the pipeline. So this pipeline visualization gives us the ability to also show, what changes are in each stage of that pipeline. Like what's in the UAT stage right now that's ready to be tested?

Where is this set of changes that, I as a developer have started pushing through the pipeline and, like, how far through the pipeline have have they been released yet?

We've introduced a concept of a work item, which is basically a ticketing system, that is not only, like, where those requirements would would be defined, like, you would think of a work, item or a ticket, But, also, it's where the changes are tracked throughout the entire life cycle. So you can we're using that as not only a tracking mechanism, but also visual indication, like, within that pipeline where a set of changes, exist. So those are a couple of things that I think just the visual and the and the UI based experience help with, in an experience like this. So I think similar to some of the things you guys are working through. Yeah.

I was gonna say that makes a ton of sense.

It it it feels like we we've heard upon a lot of the same things there. I guess one one of the things you called out is one of the ways I think we differ, and that's in terms of how much we lead with kind of branches versus the idea of a work item. I know that DevOps center is really kind of work item centric and puts that front and center.

I guess, can you talk a little bit about kind of the relationship between work items and branches and and how you actually made that choice to lead with the work item rather than lead with kind of the branching stuff?

So I think we made the decision to sort of lead introduce the work item for a few reasons. One is I just think it's, again, it's sort of a natural way people think about about changes, that they're making. And it's interesting for us because we hadn't had that concept in in our products really in the past, but what we found is that's how people thought about their change stats. And that's how people thought about, like, how they were moving changes. Was it it was all, like, based on some requirements, some ticket that came was coming from Jira or something. So it made sense for us, to kinda bring that more front and center.

It also is is providing us with an ability to sort of abstract away some of the maybe perceived complexities. So we do have an underlying branch in the source control repository that is associated with the work item. And, you know, we are managing all of that behind the scenes for our users, and we've taken an approach of trying to, like, again, abstract away some of this source control stuff from users who may not be so familiar with it, but allow them to to benefit from the power of it, but also not hide it so much that they don't know it's there. Like, we want people to know it's there, and we want people to understand that they're they're they're using a source control system.

And similar to what I, you know, just occurred with the with your pipelines product, similarly, we want people to be able to work outside of our UI in a source control system directly and have everything work together. That like, that's really important as well. So, we, like, we are using that as a mechanism to tie to a branch in the storage control system to then move those changes through the whole pipeline. But trying to do it in a way that is still, you know, not overly intimidating maybe to users who aren't familiar with it.

I think the jury's still out really on, like, where is that that line? And, you know, it's one of the questions I was gonna have for you is, like, you know, we've we've had to kinda figure out, like, where what is that line of how much do you put in people's face versus not deal knowing that you're dealing with, like, a wide range of of user types. And, you know, maybe we've started with more of an approach of trying to abstract it a little bit more, maybe partly because of the audience that we're initially trying to to to serve here.

But I imagine you had similar sort of decisions to make about, like, how much do we wanna expose these concepts within the product.

We did. But, honestly, talking to you, you're making me question my life choices, Karen.

I guess joking aside, we, I I think one thing we've always done pretty well is is kind of help people get started adopting Git. And I I think some of our biggest success stories, the the ones that I hold closest to my heart and some of our longest standing users, are are the folks that kinda started out using chainsets, and then they picked up GearSet to do org to org comparison deployment. They weren't even necessarily thinking about source control at that point. But then they've brought in source control, and then they've brought in CI.

And now some of those folks, like, they look after the source control system for their orgs, and they're they're the first point of contact for anybody low code who's doing anything with the source control system. And that that to me is like a it's a real kinda heartwarming success story and something that that I'm I'm really kind of fond of. I think in GSA, in general, we've never really shied away from kind of putting the terminology at the front and center, so talking about branches and merging and pull requests and those types of things, but we just abstract away the complexity of creating those things.

And I think we kind of took a similar approach in pipelines where I think, mechanically, a lot of the stuff that we do and a lot of the stuff that that I think you folks do, it's it's sort of quite similar.

But whereas you folks lead with the work item, we tend to lead with the concept of a branch, and then you can attach Jira tickets to that branch, hopefully, folks saw during, during Ollie's demo. And then those work items follow that branch through your source control system. But I think we were trying to kind of maybe, like, lean on the educational side a a little bit more and say, hey. Well, we think to be really effective with this stuff, eventually, you have to have a bit of an understanding of the broad strokes of how this stuff works. So we kinda wanna hide some of it or at least let let you do some of it without having to dig into all of the nitty gritty details of Git.

But, hopefully, along the way, we can help you pick up the broad strokes so that you're less likely to get stuck in a corner if something goes wrong or something like that. That's kind of our thinking and a little bit of our philosophy, but we're still in pilot with the pipelines product too. So, you know, we're still taking feedback. And who knows?

We we're not, like, completely committed to that path either. If if the feedback we get is that, you know, we we just prefer to think about this in terms of work items and tickets, then, you know, we can make that switch too. May maybe we'll see. Yeah.

So so keep the feedback, Kermit.

Anyone? Very similar. And and one thing I will say too is I think I don't know if I've been surprised, but just, like, pleased that the response that we're getting, with our pilot is very, overall, like, positive, just about the use of source control in general as part of the system. Right? Because it is new for folks. And so the fact that people are happy and eager to adopt a system that is at least, leveraging that, I think, has been a really positive sort of validation for us as well.

Makes sense. And I think we're probably coming up on time for questions real soon. So maybe to just close this out, we can think about kind of the the overall space of Salesforce DevOps a little a little bit more and kind of project that a bit further forward. Obviously, as the platform keeps changing and the way we build stuff is constantly changing too, what do you think the next key areas of focus will be for Salesforce DevOps as a whole?

Yeah.

So, you know, looking toward our GA, we're really we're looking to provide a solid experience here for our sort of lightning force based Salesforce platform platform development, org based development, for these kinds of users that we've been talking about here.

We'll continue post that to add additional, like, development models to that, so, like, packaging and sort of all the the standard, like, layers that we would add on to that. I think that's pretty straightforward.

Looking forward, though, I think where we really wanna see this go is that we're gonna, that we want to provide a unified DevOps experience for our entire Salesforce platform, like, larger Salesforce platform and beyond what by that, I mean, beyond, like, our traditional lightning based platform development. So at Salesforce, we have other platforms that people do development on. MuleSoft and Tableau and Commerce Cloud Marketing Cloud and Roku and all these different different platforms that operate differently. And, so one of the big sort of strategic things on our side is to develop this unified solution that supports all of the different types of development that you could be doing at Salesforce. And that's not just limited to this DevOps center. That's, you know, goes to our CLI and our other our packaging capabilities need to support these kind of cross cloud, capabilities, and that's one of the big things that we'll be working on over the next years.

Yeah. Yes. Indeed. That that makes sense. I I kinda feel like the category itself is still pretty new, and I I I kinda feel like even this core problem, there's probably a good few years left, in just making a real good job of of solving the core platform issues that folks are facing today with with this type of stuff.

Exactly. Yeah. I always tell people, like, there is no shortage of road map here. So Yeah.

We got plenty of work to do for years and years. So I see. It's exciting. I think it's it's fun.

It's fun. You know? I'm sure you would agree. It's fun to be solving real problems that people definitely have.

Great.

You know? It just resonates. It just the whole this whole space resonates really well. I mean, going back to some of your earlier comments, it's about how the development models and patterns have evolved over the years that really drive the need for Those and solutions for this stuff. So It's pretty cool.

That sounds pretty good.

And I I I think we're kind of in agreement about kind of the the the longer term of the problem. I think, one of the things that we find that might be quite interesting, like, an an interesting problem to tackle is is to kind of help teams make that cultural shift towards the DevOps mindset as well. I think one side of it is providing tooling, but then the other side of it is providing kind of the the support and the training and the education that people need and then just kind of taking people through the steps that are necessary to get there. I'm not trying to rush people to the end, but walking them through that process.

I know, like, some of the other speakers today, they've spoken about some of the the the classic DevOps reports from Dora and stuff like that. And I know that there's, like, a massive gulf between the low and the elite performers and those types of things. And it always kinda feels like the low performers if if you read through those things, the low performers, they invariably struggle with that cultural aspect. Like, that that's almost like the biggest blocker.

You can kind of start adopting the tooling, but if you don't make that cultural shift, you're never really gonna make it past mid table. And those really elite performers, they either didn't really suffer from that thing ever or they've managed to overcome that kind of cultural inertia. So I think one of the one of the things that that's kind of interesting is that for us going forward is also think thinking about how we can bring the engineering sides of organizations and and the business side of organizations and help them work more closely together to overcome those cultural problems too.

So the I I just invested so much stuff to do in this space. It's it's it's super fun. It's gonna be a great few years, I think.

Anyway, we should, Yeah.

We should we should hand over to Jason for any questions that have come in, I think.

Yeah. We we do have quite a few. We'll try and run through a few of them in the last few minutes we've got.

The first one is is, I guess, probably more aimed at you, Karen, around is the idea of Salesforce Stable Center to replace things like change sets and other tools, or is it a complimentary addition to them?

Yeah. As far as change set goes, this is intended to replace change sets over time. We're trying to provide a solution that, like, does functionally essentially, what you're what you're doing with change sets, but but more and in and in a better way. So we're not gonna, like, drop change that's the day this releases or anything. We'll have some kind of end of life plan assuming that people can adopt this and feel that it it meets their needs. We would prefer to have this be the thing that that lives on.

Can I jump in with a follow-up question? For you again, Karen. Sorry. I guess, does does that mean that, you think the kind of org to org deployment model will be a thing of the past? Is is intended that all of those types of deployments will go through Git at some point?

That is our our hope and desire is that there is always a storage control system backing backing this. Cool. Yep.

I like it.

And that's one of the things that I think, you know, we will learn when this is GA and this is out there is, you know like I was saying earlier, it hasn't been a blocker yet, that I've heard, and I think that's that's a positive indicator. But I think once it once it's really out there, we'll we'll learn for sure, what that model looks like. But that's that's our goal.

I mean, I think we would all agree that's probably the Noble goal.

Yeah.

A noble goal and what we would like to recommend. So yeah. Stay.

Alright. Next one is for you, Matt, and it's how is Gearset leveraging Salesforce DX?

That's a good question.

I guess DX is like a big compound thing, that's comprised of lots of different moving parts. So I think we kind of we we use some aspects of that heavily, and we we do our best to integrate with all of the bits that we see people using on on a daily basis. I suppose if you're asking about how we actually lean on some of that stuff and use it, Obviously, we're pretty fond of the DX repo format. I think that was a great step forward. I don't think anyone will will disagree with that, that the the the DX source format rather than the OG metadata API format, is a a significant improvement.

But I guess some of the other things that we lean on are things like source tracking, which, again, at its current stage is not necessarily perfect, but it's a really good step in the right direction. And we use things like source tracking to do stuff like cache metadata behind the scenes when we run comparisons in Gear Set, so we don't have to download all of the metadata each time. We can kind of get a few hints from from source tracking to to helps along the way. Although if anybody else at Salesforce is listening who has the capability to make some more improvements to source tracking, then, I I I got a few suggestions for you if if you if you wanna give me a call.

But I'd say I'd say mostly DX is kind of an incremental improvement on top on on top of, what was already there by the metadata API. So Gainsight doesn't really mind whether we're interacting with DX related stuff or, I guess, kind of all older school formats. We just kinda treat it all the same. But we'll we'll keep leaning on on that sort of tracking stuff as it keeps getting better for sure.

Sounds good. There are a a a pile of other questions that have come in, but, unfortunately, we're probably not gonna have time to run through them. So if you have time, Matt and Karen, it would be great if you can hang out in the chat and sort of run through some of those and the rest of the team can can feed them in because there's a lot of people with lots of great questions about this sort of stuff. It's clearly a hot topic for people to run through.

But, unfortunately, we are gonna have to call it there on timing. So I have to say thank you once again to Karen and Matt for your time.

It's great for the presentation and for the the q and a, and, thank you for having us with us.

Oh, thank you.

Very much.