Karen Fidelak is the Product Manager for DevOps Center here at Salesforce. DevOps Center is a new product at Salesforce that provides an end-to-end experience to help low code and industry-pro developers manage their changes and releases while developing on the Salesforce platform. Through DevOps, developers of all kinds are able to work together when they have been incompatible in the past.
In this episode, we talk with Karen about DevOps Center, what it means to admins and developers, and some of its details and implementations. We discuss the goal of bringing everything together and the modern best practices to provide a better and easier-to-use, more modern interface.
Listen in to learn more!
Show Highlights:
- How Karen got into product management and with Salesforce.
- What the day-to-day looks like for Karen at Salesforce.
- What DevOps Center is and how it helps all types of developers.
- The three benefits of leaving change set behind and moving forward with DevOps are.
- How GitHub integration works.
- Where CI CD comes into play with DevOps.
Links:
Episode Transcript
Karen Fidelak:
Where over the last several years, we’ve been working on bringing more modern kind of expected capabilities to our platform for our developers.
Josh Birk:
That is Karen Fidelak, product manager for DevOps Center here at Salesforce. I’m Josh Birk, your host of the Salesforce Developer Podcast, and here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Karen about DevOps Center, what it means to both the low-code and code people, admins and developers alike. We’re going to get into some of the details and implementations and the intent of it. But we are going to start, as we often do, with Karen’s early years.
Karen Fidelak:
Yeah. So basically, that’s the degree that you get when you want to go into engineering at a liberal arts school.
Josh Birk:
I gotcha.
Karen Fidelak:
Because of all the other requirements that are required, like in humanities, and English, and foreign language, it’s really hard to get a full engineering degree in four years, and so they do this undergraduate engineering sciences degree. Then, we stick around for a fifth year, basically, to get the full-fledged engineering degree.
Josh Birk:
Ah. Interesting.
Karen Fidelak:
Yeah.
Josh Birk:
Interesting.
Karen Fidelak:
Yeah.
Josh Birk:
Was this something you always wanted to get into?
Karen Fidelak:
I was always kind of drawn toward math and science. I was sort of on the techie side, but no. I didn’t necessarily think I was going to go in, straight into engineering or become an engineer. That’s partly why I ended up at a liberal arts school with those options, but I did like that option of having sort of a track that I could go try engineering but not have to be really super intense about it right from the start. So it was a good fit for me.
Josh Birk:
Got it. What’s your earliest memory with a computer?
Karen Fidelak:
Oh gosh. I remember my dad getting a, this is going to really date me, but a TRS-80, otherwise known as trash-80.
Josh Birk:
I was just going to say I think we’re both of that generation, of the trash-80 generation. Yeah.
Karen Fidelak:
The trash-80 in our house, because he has one for work, and he got one in the house to be able to do his spreadsheets.
Josh Birk:
Wow.
Karen Fidelak:
I remember, this is a funny thing I remember about it. I remember as soon as that thing came into the house, I was sure we were going to get robbed, because we were fancy and had a computer in the house. I was then convinced that the house was going to get robbed every night for that trash-80.
Josh Birk:
Nice. Yeah. Back in those days, they were like … I had to go to one of my dad’s friend’s house to use, I think what might have been my earliest interaction with a computer. In a recent interview, I’m just going to give a quick shout-out, one of my guests was like, “Yeah. In India, computers were so rare that ours was in a carpeted room that you could not go in wearing shoes. All security measures were on so that the kids can’t destroy this thing.”
Karen Fidelak:
Yeah.
Josh Birk:
How did you get involved in product management?
Karen Fidelak:
So coming out of college, I was on the tech side, but, again, wasn’t super sure I wanted to go into hardcore engineering. I went to work for a semiconductor company and was basically working in their tech support on their hotline, their tech support hotline. This was basically how they brought in all new college grads. It was a way to just dive in feet first and learn product. Right?
Josh Birk:
Mm-hmm.
Karen Fidelak:
You got to answer technical questions with customers who are using very technical products. The product itself was a programmable semiconductor device that had a very pretty complex software package that went with it to program those devices. So a lot of the questions that we would get were more on the software side, and even though my background was more electrical, I was tending to sort of gravitate more toward the software side of things. But I didn’t have any background in programming. So I kind of, throughout my career, just found myself gravitating toward sort of these roles that sat between the engineering teams, the business, and the customer, and in my earlier days, again, dating myself a bit, before product management was really even a thing, we called it technical marketing or application engineering or things like that.
It was basically like helping kind of bridge that gap between the customer, and the business, and the engineering teams building our product. It really was product management, but just under a different title. And so I’ve sort of always kind of been in that kind of field, but I think in about, I think, 2017, or no. That’ when I came to Salesforce. So 2010 is when I first got my first role that was actually titled product manager, but it was doing very similar things that I’d been doing. So I’ve been, really, doing that for a long time.
Josh Birk:
That explains like … Because I have to say when I was looking through your LinkedIn and stuff, I’m like, “Technical marketer? Karen?”
Karen Fidelak:
Yeah.
Josh Birk:
So that, now, that, now it really makes sense. Now it really makes sense.
Karen Fidelak:
Inbound. Another title for that is inbound marketing.
Josh Birk:
Really?
Karen Fidelak:
So we would have inbound marketing and and outbound marketing. So the inbound marketing was all about working kind of like with the internal people at the company versus going out and delivering that external customer-facing message.
Josh Birk:
Gotcha.
Karen Fidelak:
Yeah.
Josh Birk:
And product management kind of turned into all of that combined.
Karen Fidelak:
Yeah. So then, product management kind of covers it all.
Josh Birk:
Got it.
Karen Fidelak:
Yeah. That’s kind of one of the fun things about product management, is it spans this huge, big spectrum of being super strategic and visionary. I’m working, on a daily basis, with engineers building our product, working through very specific features and stuff.
Josh Birk:
Nice.
Karen Fidelak:
So it’s pretty cool.
Josh Birk:
How did you get involved with Salesforce?
Karen Fidelak:
So job that I had previous to this was with a kind of smaller startup company in Boulder, Colorado, so I’m based in Colorado. This company made smart energy software products, and it just so happens that there was a few folks there who left during my early time at that company to come to Salesforce and basically started the Colorado office of Salesforce out here. It was platform engineering at the time, is what that focus was. Then, over the years, I just stayed in contact with these folks, and a lot of the people who are at Salesforce in Colorado right on the, particularly on the platform engineering side, came from that company who were these folks.
Josh Birk:
Gotcha.
Karen Fidelak:
So yeah.
Josh Birk:
Interesting.
Karen Fidelak:
It’s a very small network of folks out here, but long story short, I got to Salesforce through people that I had worked with previously.
Josh Birk:
Got it, and I always like to ask this question, because I always get at least slightly different answers. But how would you describe your job, like the day-to-day job at Salesforce as a product manager?
Karen Fidelak:
Well, these days, I’m spending a lot of time interfacing with our community on our new product that we just launched, which I’m sure we’ll be talking about, and I also spend a lot of time interfacing with our engineering team, who’s building this product.
Josh Birk:
Gotcha.
Karen Fidelak:
So it kind of varies throughout the year, depending on where we are in sort of our release cycle, what our day-to-day looks like. Sometimes, we’re in a big planning phase, and actually, we’re in our annual planning phase at Salesforce right now, as well. So we’re looking forward to what this next fiscal year is going to look like for our products, because we’re doing some more sort of strategic work there. We’re also continuing to build products, so we’re having to make sure that the teams know what they’re doing and we’ve got all our priorities straight. Then, we’re dealing with all of our customers and our users who are using the product, and that’s super fun, as well.
Josh Birk:
Nice. Okay. Speaking of that product, what is the elevator pitch for DevOps Center?
Karen Fidelak:
Yeah. So DevOps Center, this is a new product that we’ve just introduced. It is providing what I like to call an end-to-end experience to help developers of all types manage their changes and releases as they’re doing development on the Salesforce platform. So one of the key gaps that we have been trying to solve for over the last several years is to provide a more modern, kind of best in class, modern best practices experience for, particularly, or low-code and declarative users who have not been able to take advantage of a lot of the modern goodness that comes with software development, particularly around some of the new capabilities that we’ve been building at Salesforce around Salesforce DX for our developer community. And so many of you, I’m sure, are aware of our Salesforce DX capabilities, where, over the last several years, we’ve been working on bringing more modern, kind of expected capabilities to our platform for our developers. So what we’re now trying to do is make sure that those developers can work alongside our low-code developers in a way that leverages all that modern goodness.
Josh Birk:
Well, and that was a question I had a little bit down the road. I can’t remember the first time I heard the term fusion or hybrid team, but describe the overall roles on a team like that.
Karen Fidelak:
Salesforce was originally really focused on low-code development, click-based development, clicks, not code. Over the years, we wanted to bring along now only those low-code developers, but also these more industry pro developers. And so that’s really been a lot of our focus on Salesforce DX, with Salesforce DX, is to bring those pro developers along. Well, now, what’s happened is we’ve got both pro developers, pro code developers as well as those low-code and no-code developers wanting to work together on a team. Right? So some may, our low-code developers may be doing declarative click-based development using our builders, our declarative builders, alongside our pro developers who are writing Apex and writing LWC. Those are all part of the same application, and so those folks need to be able to work together. Right?
They need to be able to see each other’s work. They need to be able to test each other’s work together. They need to be able to manage that work together, and that’s been a real challenge, quite frankly, until this product has come out. Because the technologies that we’ve had to manage those two different types of developers working together have not be compatible. And so what a hybrid team is is we’ve got low-code and pro-code developers working together collaboratively but using tools of their choice, where they’re comfortable, and tools that they prefer to use. But everything can be done together.
Josh Birk:
So to dig into that a little bit more, it … Because change sets feels like the world of admins, and then we do deployments and all of this kind of stuff. What are the big benefits for using this and leaving change sets behind?
Karen Fidelak:
Yeah. So there’s a lot of reasons to leave change sets behind. In fact, we-
Josh Birk:
Every admin listening to the show right now is like, “We know.”
Karen Fidelak:
Yes. In fact, we, as part of the release of this product, were able to retire over 75,000 points on IdeaExchange related to change set enhancements.
Josh Birk:
What?
Karen Fidelak:
Yes.
Josh Birk:
No.
Karen Fidelak:
So there have been 10-year-old ideas out there requesting changes, and improvements, and enhancements to change sets, and DevOps Center’s really our answer to that. So to answer your question, the UI that came with change sets was just really old, and clunky, and very hard to use. Just things like pagination wasn’t good. Couldn’t easily search, sort, and filter. I mean, it’s just really hard to use from that standpoint. Also, it doesn’t take advantage of any of kind of these more modern technologies, particularly source control. So we’re really moving in a direction where we want everybody, and our community is also looking to embrace these more modern technologies like source control. Change sets just really didn’t allow you to do that.
The third big point is, again, it didn’t allow you to work collaboratively with your other counterparts on your team that were already using and taking advantage of these more modern technologies, like with Salesforce DX. And so what we’re trying to do is bring all that together, bring modern best practices, and provide a better and easier-to-use, more modern interface. So I think all of that combined really should move the needle to help people see real value in this as an alternative.
Josh Birk:
Yeah. Tell me a little bit about the GitHub integration. How does that work?
Karen Fidelak:
Yeah. So we have felt that it’s really important for all developers to be using source control, meaning that they’re managing their source, their changes, their metadata, really, ultimately, is what it is, outside of the org. So don’t want that org to necessarily be that source of truth. We want that source to be managed externally, and that’s going to give us a few things. Beyond just having that external repository where we know that source is safe and managed, it also adds to that the benefits of collaboration across a team, visibility across a team, knowing that everybody’s working against that same source of truth. So it’s really important that we have that as part of the overall experience and solution, but we also acknowledge that not everybody is familiar with using source control.
A lot of these Salesforce developers have never had to deal with it before. They aren’t necessarily traditional software developers that have grown up learning how to use a source control system, and that’s totally fine. But what we’re trying to do is make it easy for everybody to adopt source control so that you can get these benefits of it even if you aren’t familiar, you haven’t used it before. So we’re trying to basically lay a layer of abstraction on top of that source control system and repository to help you manage that through simple clicks in the DevOps Center UI. I feel like we’ve done a really nice job of making this integration really easy, pretty seamless.
You really just need to be able to log in to GitHub, have an account, and then everything’s going to be handled and managed underneath the hood by DevOps Center. Then, if you are that pro-code developer who wants to just get into GitHub, and commit your changes through a CLI, and use the IDE, and interface directly to that repository, you totally can. That’s the beauty here. You can do that, and you can work alongside those, your local counterparts who are using DevOps Center to interface to that same repository.
Josh Birk:
So if I’m a developer that’s not … I don’t necessarily have to change any of my flow, and if I’m not a developer, it’s literally as easy as logging into GitHub. Then, DevOps just sort of syncs everything in the background for you.
Karen Fidelak:
Right. Right. So that is really exactly right with the pro-code developers, and I’d like to just reiterate that. Because we have, I have these developers coming up to me. They’re like, “I don’t get what the benefit of this is to me. I don’t want to change what I’m doing,” and I’m like, “You don’t have to change what you’re doing. That’s the whole point here.”
Josh Birk:
Right.
Karen Fidelak:
“We are providing this tool so that the rest of your team that’s not doing what you’re doing can now do it.” And so we hear examples of folks that are frustrated and tearing their hair out, because they are working in a source-control-repository-based system. They’re using maybe CI and CD. They have that level of visibility and control over all of their sources. It’s going through their lifecycle, but then, meanwhile, they’ve got these low-code admins who are making configuration changes and moving them through change sets. The source control system has no knowledge of that. Right?
Josh Birk:
Yeah.
Karen Fidelak:
And so they’re frustrated about that, and see. That’s the problem we’re going to solve here for you, is that everything’s going to be in your source control repository so you can see it, and everything’s in one place. So that’s really the benefit there, and sure. If you want to use the click-based interface, you absolutely can, but I think the real value is we aren’t necessarily saying you have to change what you’re doing. But you’re going to be able to see the benefits across your team.
Josh Birk:
Right, and I want to double down on that last part. Because I think you’ve described it, but just to give it another call-out, the benefit to me as a developer isn’t the fact that I have to go into the Salesforce org and use DevOps Center. It’s the fact that now, we’re all in the same repo. The admins don’t have an excuse not to use it anymore. It’s as simple as logging into GitHub and walking away, and so now, we all have a source of truth, which is benefiting everybody.
Karen Fidelak:
Exactly. Everything’s being managed in that same repository. You can all see it.
Josh Birk:
Nice.
Karen Fidelak:
You can all review each other’s changes. Yeah.
Josh Birk:
You mentioned CI/CD. Is there any angle there? Does it integrate with any kind of CI/CD, or does the world of CI/CD still just sort of work in whatever the developer lifecycle is right now?
Karen Fidelak:
Yeah. So right now, basically, the way I describe it is DevOps Center can work alongside an existing CI/CD system that you have set up. If you think about part of this value proposition that we’re saying, which is you can do things inside or outside of DevOps Center, and everything stays in sync, that inherently means that if you’re doing things outside of DevOps Center through a CI system, then DevOps Center can recognize what’s happening there. So as long as everything is being automated against that same repository and, essentially, against that same project, then DevOps Center will reflect what’s happening, and so people can see it within the DevOps Center UI. If you want, users of it can see where the state of everything is, but yeah. It’ll just work interoperably next to it. Just to add to that, we do, on our roadmap, safe harbor forward-looking statement here want to incorporate more of an out-of-the-box CI/CD experience to this in the future, so build some of that automation more natively into the experience.
Josh Birk:
Well, and that was one of my follow-up questions. Do you have anything else on the roadmap you want to give a shout-out to?
Karen Fidelak:
Oh. We’ve got lots of stuff on the roadmap. So I mentioned, and we’ve talked a lot about source control. I mentioned GitHub. Right now, GitHub is the only source control system that we are integrated with. It is also a requirement that you use source control with DevOps Center. So that means that if you are not using GitHub right now, you cannot use DevOps Center. So that is our biggest blocker to adoption, and so therefore, that’s really our big priority right now, is to make sure that, or is to start bringing in the other Git-based providers as integrated solutions.
So the first one that we’re going to be looking at is Bitbucket, and we’re looking at this purely from a, kind of a numbers game right now, so who’s using what, what we’re hearing from our customers based on survey data that we have. So we’re starting with Bitbucket. The other ones that are on our roadmap are GitLab and Azure Git, and we’ll also be looking at enterprise-level GitHub as well as the others. So that’s kind of one of the big things for this year. We’re also looking at a lot of just usability enhancement, specifically around kind of what happens when you’re promoting changes through your lifecycle and things don’t go entirely as expected, which is entirely what happens when you’re doing development.
You’re testing things. You find problems. You need to fix problems. You might need to quickly get a fix into production through some kind of hot fix path. So we’re looking at a lot of these kind of workflows around what we’re calling kind of the less happy paths. They’re very standard, valid paths, but they’re just not necessarily everything’s going swimmingly from left to right. And so we’re trying to make those experiences a little bit better and more easy to use. We’re also looking at several other types of integrations and the ability to further customize and extend the application, which I can talk a little bit more about, as well. But final shout-out, though, is we do have our roadmap publicly published. It’s in a GitHub repository.
Josh Birk:
Love it.
Karen Fidelak:
I don’t know if there’s a way to share a link here. Do we have show notes?
Josh Birk:
We have show notes.
Karen Fidelak:
We have show notes. Okay. So yeah. So we can add a link to the public-facing roadmap in our show notes here.
Josh Birk:
Okay.
Karen Fidelak:
We’re sharing that, and we’re also looking for feedback on it, so tell people that.
Josh Birk:
Which conveniently answers my next question, which was how people can learn more about that or about this. Is that the best location?
Karen Fidelak:
Yeah.
Josh Birk:
Okay.
Karen Fidelak:
So the best place, well, the best place to go to learn about the product is our Trailblazer community group, something else to put in the show notes.
Josh Birk:
Yep.
Karen Fidelak:
That has got a bunch of links to other documentation, blog posts, demos, and also the roadmap. So that’s where I like to point people.
Josh Birk:
Got it. Is this an extra license?
Karen Fidelak:
This is not. This is included with Professional, Enterprise, and Unlimited editions at no cost.
Josh Birk:
Nice.
Karen Fidelak:
It’s also available. You can use it in Developer Edition orgs and Trailhead Playgrounds if you want to try it out.
Josh Birk:
Nice.
Karen Fidelak:
So it’s just available right through setup. If you go under setup in any of these production orgs, you can find a DevOps Center page where you can enable and install it right from there.
Josh Birk:
Very cool.
Karen Fidelak:
It is a managed package that gets installed into the org.
Josh Birk:
That’s our show. Now, before we go, I did ask [inaudible 00:21:42] Karen’s favorite non-technical hobby.
Karen Fidelak:
These days, I like hiking in the Colorado mountains here with my dog and my husband.
Josh Birk:
Nice. Aw.
Karen Fidelak:
So yeah.
Josh Birk:
Aw.
Karen Fidelak:
We like to get out and explore our beautiful state here.
Josh Birk:
I want to thank Karen for the great information and conversation, and as always, want to thank you for listening. Now, if you want to learn more about the show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Thanks again, everybody, and I’ll talk to you next week.