Description
Whether you’re just starting to grow your team, or have an established team working to optimize your release process, the hardest part is establishing a strong foundation that will work both today and for years to come. DevOps Leader and Staff Engineer Ray Ensley presents a webinar packed with practical advice on building and scaling a successful Salesforce DevOps team.
Ray has been working with the Salesforce platform for about 12 years, and has been implementing DevOps for about 6 years. He’s worked on Salesforce instances large and small, as well as solutions both on and off the Salesforce platform.
- Learn how to establish a rock solid foundation for effective and efficient releases
- Gain leadership skills to create a process that works for your team’s unique requirements
- Discover how to effectively onboard and share knowledge with new team members
- Incorporate an effective peer review process that promotes best practices and team success
Related videos:
Transcript
My name is Ray Ensley. I am a staff engineer primarily working on the Salesforce platform. I've been working with Salesforce now about twelve going on thirteen years.
In addition to Salesforce, I've also worked on a bunch of different, full stack applications like building on AWS, building integrations, that as well as a slew of ETL tools.
That's a thirty thousand foot view of myself, but feel free to ask me any of the other questions that might come up so just wanted to give a quick rundown of agenda what I'm planning on covering today. We'll kinda go through just like an interest out of some ground rules of what I'm gonna be covering, some common pain points potentially, and then really how to establish that foundation to to scale a team in going forward and implement a good DevOps practice at your at your place of work or however using Salesforce in general.
So I mentioned ground rules. I wanted to say, I I am the tech person who I like interactivity.
Please ask questions.
There should be a a question feature here in Zoom. Feel free to post them there.
If they come up to the chat, we'll try to get to them. I'm gonna try things moving a bit. I will have time at the end for additional questions. If we don't get to them, I'm happy to to kinda stick around and answer questions at the end too even a little bit past the webinar time. So feel free to please, please ask questions. I like realistic use cases.
So I'd like to, John, just talk about just what this practice is. Like, really wanna see how it can apply to you as well.
Some general themes that I'm planning on covering is, really establish a process over tooling. It don't like to emphasize, like, use X tool to solve your process. I know this is primarily a gear set launchpad, webinar, but truthfully, it's really about establishing a process and then finding the right tool to fit whatever processes that you establish.
With that being said, I am going to make some assumptions around using gear set and Salesforce primarily. I know that's not gonna fit all use cases, but If there's any other use cases that we need to cover, I'm happy to answer questions about that towards the end. But I am making a slight assumption that we will be using to your set in this case. So some of those examples are geared in that way.
Another common two common things I wanna I wanna, like, go through is, setting up and following a best practice is not the only best practice. There's multiple best practices, and it is very much to what fits your needs and for what your team is there. But you might not have that defined So we're gonna go through that today.
Just for in the sake of time, if anybody wants to kind of post in the chat, like, just roughly a little bit about your team, your current team size, and kind of makeup, feel free to put that there. And if anything, any questions around that jump out, we can absolutely go through that.
So to start off, what makes a great process for scaling a team?
So some of these things that they seem as very obvious things, but in truth and in practice, they really aren't.
A good process to scale has very clear guidelines.
It has promotes collaboration amongst your team The big thing is it can handle the unknown unknowns, meaning things are gonna come in at any given time. Like, how do you handle them? Can you be flexible and handle them as they come up.
Good practices and good things that'll help you scale your team as you add more people. You might be three people today. What are you going to be when you're ten people? Twenty people, thirty people and so on is how do you handle that and making sure that you can facilitate that. You have to be flexible and willing to acknowledge change.
Most people here, kinda make a side assumption work in tech some form of technology that you might work with, you know, any tech space of a non tech company, but things change very fast, typically. So if you need if you cannot be flexible with those things, it's gonna be hard to scale any practice as you grow that team.
And my favorite and least favorite thing to say is document document document. I'm a type of person who if you asked me ten to fifteen years ago, hey, write everything down as you go through it. I would tell you you're crazy. I'll remember it, but the matter is if you don't document your practices, you're going to get a lot of thrash that comes in of asking you how to do x or how do we move by, or how do we incorporate a new, like contractor or somebody else coming into the process, write everything down as you're going through and establishing a It's like, even if it's just bullet points as you're going through and running through a, like, deployment pipeline or establishing all that out, your team will grow. So you might only have five people today, but in ten people, now you have nine more people coming to you and asking you questions. If you have something written down that you can share out, It helps save a lot of time because it becomes more of a self-service model.
So when we start on the journey of defailing a pipeline and best practice for DevOps, there's some common hurdles that come up and also some common assumptions and and things. Might get requests to come in on, like, you're gonna have a requirement to build a product. Your developers, your admins, your program managers, whatever your team makeup might be. You come up with a solution, you build that solution, and you deliver it.
Great. It's out the door. But then what? So you'll get you'll get different things to come in to enhance that product, or you'll get tickets to support that product, or six bugs so on and so forth.
It doesn't just end at delivery, which I feel is a typically common misconception of, like, We have this feature out there, but we don't really compensate of what happens after the fact. Like, how do you make sure that you're aware of what's going to become after you deliver a feature. Having a good foundation of, like, how you facilitate that will save your team a ton of thrash and a ton of time.
Especially as your business grows, it might grow faster than your team. So if you have a good foundation that's in place, Think about how, like, contractors that might come in or consultancy might bring in. Think about how those things would be solved with those delivery like, how can you ramp somebody up very fast to get them out the door?
So I have a general question here for the room.
Is there any common scaling or pain points that maybe your teams have, that you're commonly thinking through right now, you can post them in the questions here. I'll try to get to them.
Nate, I see you had a question around your your team size. You have three admins, four devs, and five BAAs.
Had all metadata package creations, apps, objects.
Kinda cut off here.
Sorry.
Nate, I'm gonna answer your question towards the end because I think it's more, just kind of general overview if that's okay.
This kinda may go into that as well, Nate.
So the first thing you might wanna do is is similar to that is what is your team and who are is on your team in terms of skill sets. Right? Because at working with Salesforce, not everybody is going to be of the same technical level. Some people may have used Salesforce before.
They may come in with a lot of great ideas. Some people may have not even seen the platform before, and this is the first time they're interacting with it. Or you might even in a a more granular level, you might have administrators who aren't familiar with things like git branching, version control, SFDX, any of these, like, more technical tools that your development team might be more aware of. You need to really think about who is on your team what they're capable of and what are the common skills that you can work towards?
Not everybody is gonna be equally as technical, but you're only as strong as your weakest link. So if you have a team that is defined, you need to figure out a way to make sure that everybody can be efficient. Not just one group or one skill set to be efficient.
There's a phrase I I typically like to use a lot, which is when as a team fails a team, It's very, very true in development. I think you can build any feature you want, but if not everybody can operate at the same same process or cadence, you all will fail because there's bugs that get reported, but it's your team. It gets reflected on any individual person or group or anything.
Another thing to consider when you're you're really going through this is who are your consumers?
Like, what What are they actually caring about that you deliver? Like, how do they interact with your team? They they may not be directly on your delivery side of things. But they give you feedback, which then facilitates how your backlog is built, and that you're gonna be keeping that that wheel of innovation going on the platform.
And more and kind of more general questions as you're as you're building this out is who can make changes? Who's allowed to make changes?
I'm I've been in organizations before where we've had people come in who've said I've had systems administrator access in my previous org. I can just add fields whenever I want. That doesn't always happen. And, truthfully, from a best practice standpoint, is not a good idea, and it also makes a lot of confusion to all other users on your platform. It might work if you have an org of a hundred people, but what happens when you have five thousand people in an org and you have people just creating fields? Think about what type of access you need to grant to the people who are allowed to make changes.
And then really forward thinking, how do you make sure that when somebody does join your team, you can get them onboarded quickly to be effective and not not as worried about how to make a change. Make sure that they can do have the tools to do their job.
I I was hinting at this a little bit, but, you need to really define what your team owns Salesforce is a platform that can tend to sit in multiple different areas in an organization depending on how it's being used, and especially of all the different functionality that comes along with it. Don't let your team become a dumping ground for everything that you own. Be very clear about what your what you own.
I'm a big fan of the phrase, Jack of Alltrades, Master of None. Typically, Salesforce professionals are very, very, very capable of people who can do a lot of things and very quickly, try to be very intentional about what you own and what you're going to do on the Salesforce platform.
When you're going through this and trying to figure out what you are responsible for or what you own, think of it in the way of if I got paged at two in the morning, What am I getting it paged about?
And I'm hopefully, many of us are not in that situation, but it's a reality of things. Right? You could be called that late at night. Like, you but you don't wanna be asked about something that you have no idea that was even in Salesforce in the first place, because you weren't sure about what the ownership of the platform was. So try to try to keep it to the point of what you can own. And that way, even if you did, unfortunately, hopefully, not two in the morning, if you do get called at late times that you're able to effectively answer questions that may come up because it's within your scope of ownership.
Another thing to talk through is ownership is not just a system based feature. You don't it's we we talk about, like, a tech stack where if you may own Salesforce, you might own your DevOps pipeline running through gear set, you might own your git repository, may not necessarily just be a systems thing. It could be you have data ownership.
So opportunity data that may sit in Salesforce. Your team may own, or you might be in an organization of, well, our team owns the metadata, the business owns the data. We just have to facilitate how they store it.
Be very clear about what you own and the processes that you own there too. This also could mean data updates. Do you give users data loader? These are questions to ask as you go through and define ownership of your team.
And also just equally as important, define what you don't own. Be very clear about what you don't own.
This could be something as simple as an ETL process. You might have a data science or a a BI team that actually does some sort of enrichment on data in Salesforce. Your team may not own that detail pipeline, but you own the end target or the source of where that data came from. If you have a question that comes in for an end user, you need to know how to route them. So if you define what you don't own, it's a lot easier to help your stakeholders, your end users be a lot more self-service.
Just gonna pause real quick before continuing, is there any major questions or anything that came up?
Keep on moving.
So, Alex, I will definitely get to this. So you have a challenge in getting other teammates to record their changes in a client's change log.
I rely heavily on Google sheets config log. So many configs need to be done manually. I also like the ability of adding comments and rationale to each config config item change I'm making.
I will definitely get to that here, Alex, and as I talk about source of truth and kinda and change tracking through a repository.
Brenez, hope I have mentioned incorrectly. Documentation platform has worked for you. I've had good luck with Confluence personally, that has worked as a good centralized source. I've also worked at organizations that have, has, had some internal document tracking as well that was homegrown. That works really well.
I've done some change tracking through QuIP for documentation.
Which works really well, especially if it's integrated with an internal, like LDAP group, or you might have, because you can easily tag other people if you need input.
The the biggest thing is it just can't be a document that sits on somebody's computer. Right?
Need to have something that you can easily share, and it's easily searchable. That's that's the biggie. So if you have new people that come in, like, how do you find documentation? That's just as as important as actually writing it in general.
Did that answer your question?
Yeah. I'm gonna assume guessing this here otherwise. So going into defining things of, like, what actually needs tracking in your source of truth? Like, what is a source of truth?
Right? Some people might look at it as with both just back up and track everything. That's that's not reality. Like, source of truth is what is important.
So you need to actually determine, like, what are you actively using in Salesforce? There is hundreds of metadata types. I think that last I checked the number was almost at almost a hundred and seventy, if not over, I would be willing to bet that there is nobody on this call that is using every single one of them. And if they are, not probably every single one needs to be tracked in some sort of source of truth, a source of truth is not a backup.
That they are actually two different things. A source of truth should be something you can define of to, Alex, to your question here, do you check changes that go through? Everything should go through your source of truth first and then roll that to your target environments. There's a few things that actually will help with that.
One, it will give you an audit log and an audit history if you're using a source tree, something like git. Like, GitHub is a great, a great place to track things because you have commit history, you can see and tag, like, if you have Jira integration or anything like that, you can put Jira tickets linked in there. You can see how, like, the use cases that actually brought into it. When something was merged, when it was released, and actually all the commits that went up to that point, and what was actively changed.
And it takes a what seemingly could be a very large Salesforce org and minimizes it down to those just those few features that may have changed.
This is kind of a a bit more of probably an advanced thing once you have a source of truth established, but you can define different metadata sources within a source of truth that have ownership by different teams.
There's a feature in GitHub, which some of you may or may not be aware, to define code owners. So you can actually have groups in GitHub that own specific file orders in a Salesforce repository. For example, like, a development team can own the Apex classes where an admin team could potentially own the custom objects itself And you can split that up so that you're not successfully having certain people or certain groups that actually have to be responsible for the entire org altogether.
It helps put split things down for my seemingly large problem.
The the other thing it's really easy to see. You go through Google. You go green blog posts, everything that's out there. There's a lot of industry standards that get established, like, how to use, like, certain best practices across Salesforce and using DevOps on Salesforce is very generalized in a lot of ways.
It doesn't have to be your standard. You've you really wanna kinda figure out what works for your team, what makes your team efficient. Those are the things that you should care about. Don't just try to adopt a standard, adopt your standard and define it.
This is this is personally one of my favorite topics because it's semi polarizing is how do you review changes? How do they go into another environment or into a production org?
Code reviews are a great way to do so, but it's also a really, really broad term. Some people also might know them as pull requests.
These are things that, like, come up pretty frequently. Right? But they can also be a very nerve wracking process. Like, I mean, I they're wish I could have a show of hands here, but it's it's really nerve wracking to open up a code review and ask for feedback, open feedback on something that you have built by your peers.
That go through because you don't know. You may not know, actually, what they're gonna ask you. But code reviews don't have to just mean code. They could just meet a build review, I've previously I've worked in an org where we've had, like, flows that get green flows that get built or at net new objects that get created.
Like, a review could be I hop on a Zoom call or in a conference room with one of my coworkers. We go through it was built, and it looks good. Right? You just you can move it forward or you provide some feedback on ways to improve.
The the the review aspect of it and from, like, an approval standpoint is just systematic check at that point. On the other side of things, it can make things a lot easier to facilitate feedback if you use a system like get where you can actually ask for comments. Right? So I can I can write an Apex class, and then if I might might have accidentally misspelled a variable name?
Right? One of my one of my colleagues could go in, literally, leave a comment on that line saying, hey, you misspelled this. We should change the change how this is spelled. It's really easy to track because I know the exact line number that the edit was on, and I can also have a history that it was there.
The the flip side, two code reviews that I feel gets often lost, as you're going through in developing a good practice is you really have to promote positive reinforcement and positive feedback as well, celebrate great builds. There's sometimes that you your constantly learning. You're trying to figure out the best way to implement something net new. So think about, like, if you see something neat, tell the, tell the author of the build, like, oh, this looks amazing.
Like, just call those things out because those also could be learning experiences for the rest of your team.
The other the other side of code reviews is approvals, which can help protect your team, not just necessarily be a way to gate mechanisms from going forward. It it makes it so that there's not a single point of failure in a in a process. Right? If I Ray build something that new, and then I hand it over to one of my colleagues for a review, and they look through and say, what's good? Release it. And then all of a sudden, a user reports a bug.
It takes a little bit of pressure off of me because it, like, I I get out of my own head of saying, like, oh, I should have caught all these cases, all these corner cases that caught when realistically. It's not not necessarily one person's fault. It's just that it was a missed case as possible to go forward. It it kind of demystifies that and kind of spreads the ownership across the entire team.
One thing that's super useful that helps speed up coders use and also makes it a lot more approachable from new team members is to find a style guide. What do you actually care about in your in your builds?
So simplest the simplest example of this is every new field in a Salesforce instance should have a description.
So if you're pushing things through and you don't see a description, you put a comment on a code review and say, Hey, this needs a description before you push it through. It makes it so that there's not just one person or a group saying, like, this is the process you need to follow. It's an agreed upon a process that your entire team wants to follow.
So to the question that just came up from the chat about software for automation testing, is manual testing.
I do have some recommendations on that. There there's a few different tools you can use.
I've had some luck with some of my peers who have used, like automation testing, like, through selenium through, like, UX testing that way, and then doing test case tracking, via the via, a tool that we've used called test rail for test case tracking. That's that's worked really well.
There's a a ton of tools out there that'll work out there.
On the LWC side, if you can swing it, I know it's It's not hard enforced, but it's easier to follow with, the, LWC test and via Jasmine. That usually goes a lot wet as well.
So, have this picture of Netstar. There's always a every time I think of code reviews, I always there's a line in Game of Thrones, which It's a shame that that Joe ended after six seasons.
The man who passed the sentence should swing should swing the sword which is semi applicable to code reviews in my mind of, but don't just let some person who is, like, the senior most engineer on your team is the only one who does code reviews. It's a process that everyone adheres to. And at the same time, if a your senior most engineer or senior most admin is building something and they submit a review, they're they're available to have the same feedback that's given to any other person on the team, whether they've been at the company for one day or one year. It really doesn't matter.
Everybody is be beholden to that same agreed upon process. Again, if you establish that, that style guide, you establish, like, what your reviews are looking for, It's a bla it should be a blameless process. Right? You want everybody wants to succeed.
So you're really trying to raise the bar and make everything as the best piece of software or Salesforce feature that you can possibly release and roll out. And also, it anybody who's new to a company or maybe is just getting into a more formalized review process, it makes people feel more comfortable to give feedback. Right? You have something that you can lean on and, like, read into and say, here is why I think that this needs to be done diff in a different manner.
Like, because our style guide basically says that don't use that future methods anymore. Use everything through queueable, and you used a future method. So it's it's more of a blameless process. And it also helps promote learning.
So going through process, you've established what what matters, what you own, how you're gonna track it, how you're gonna review it. Now the important thing is, how do you wanna deliver it? So if you don't have a defined release cadence at yet, consider how you want to release, and also think about how you want to release a year from now, two years from now, three years from now, just because you can release immediately, I mean, doesn't mean you should.
So your test methods right now may be will take fifteen minutes to run. So you can get a feature of production very quick. You have feedback that comes in from from an end user saying, hey, this isn't working exactly how I I, as imagined it, you get feedback. You have a quick fix.
Maybe it's a maybe it's a permission. Right? You have a profile. And you go through your entire deployment process, and boom, you can release it within fifteen minutes.
That's totally fine if it's a bug fix. But what happens in two years if it goes from a fifteen minute deployment to a four hour deployment.
Now you get the reset expectations with your stakeholders of Hey, we used to be able to deploy one way. Now is much, much longer to get there. Be able to set expectations of when you release. Could be released a weekly release cadence, and maybe you do it every Wednesday.
Could be a daily release cadence.
Using a personal example, I was previously at AWS at one point when I first had joined in twenty fifteen, our release process took about forty minutes to deploy a feature to production by twenty twenty. It took almost nine hours to complete a production deployment.
And it was very hard to to set expectations with a lot of our stakeholders who had seen the growth over the time of, I used to be able to get feedback and features in within a day. Now our sense of ownership of the of the org has grown as well as the timing takes to get something into the org has now grown. And if any touch failure happens, get it restarted all over again.
Another thing that's equally as important to define is if you have a quick bug fix or there's a there's a an incident in your org where the entire org is down, you can't you can't do anything like what you have a feature. Nobody can create opportunities anymore. How do you do you roll out hotfixes? How do you do this? This is going back into the theme of, like, how do you handle those unknown unknowns? You don't know that this is gonna come but do you have a good mechanism in place that you could actually handle this?
Being able to have a path that you can follow and your team knows the leverage like, the levers they need to pull in order to get that released is so important. And then it also makes it so that it's not a frantic dash to get something fixed in production.
Wish I had thrown on this slide the, you know, the this is fine meme because that's, sometimes when things break in production, like, that's exactly how it feels, but want easier when you're you're kind of just moving through, moving through and kind of get things to to deploy to production.
As you're going through, like, you don't also have to jump into your delivery process on automated just to start. Keep it simple. It might be a series of manual steps to get going. Get it working first, then start automating. Start start thinking about how you're going to automate.
Again, keeping on the theme of Salesforce. Salesforce at some point will be a bottleneck.
Their APIs will handle delivery.
In one way, it does their deployments to through the metadata or the tooling APIs, again, they get released in production.
Your team is going to grow, which means more things are going to start to go through. Start having things that go through immediately, you're gonna get you're gonna get org locks. You're gonna get timeouts that happen. Think about how you can pipeline all those things through in a in a repeatable way. So it could be something like every four hours. We're gonna release something out to production. So you try to semi package all your releases into one thing.
I'm gonna move to my next slide. So, like, just like a sample, deployment pipeline. You might have a dev, a UAT, like a full sandbox UAT in a production environment, and then you have a hotfix environment where if you really need to get things through quickly, you can kinda just keep moving things through and get them through. That hotfix should only be used in case of emergency, but it helps get around, like, any of the normal builds that are going out as well. And then you can use things like gear set pipelines and kinda do back propagation as needed to make sure that all your other developers or actively going through and getting all those new features that went out. But the idea is you want the team to be efficient not necessarily moving quickly. So speed and efficiency are two different things that you really need to to care about.
And there's two other major points that you probably wanna cover is, do you support how do you support releases once they come out? And it's never really estimated.
Right? You go through you build you build things out. You estimate things out and you're you're worried about how you build things, but what does it mean to support a feature going forward? How do you estimate for that? The more your org grows, the more you at the own, which means the more overhead you have to consider when you support these things. Not support isn't necessarily given for free because there's, just because you've released a feature and it's on Salesforce, customization usually has custom logic built into it, which means you have to support it and be able to aware be aware of how to support that as well.
It's easy when you're smaller to say to answer these one off messages, whether they be via Slack or teams or or some some sort of chat software internally, or you can just give a quick response back. But what happens when your org goes from a hundred people to a thousand people? So how do you make sure that you can do that without having thrash that are that's moving you from thing to thing, just answering questions back and forth. Really think through how you wanna triage issues and funnel people. So they can come in, you can get questions answered, and they can also be happy so that they're not just waiting on somebody to respond, and then the person they asked. I've just been on vacation.
And then again, some of you may know what the what this handle is also known as, but you should also have any break glass that you can follow if an urgent issue comes in. Just be aware that anybody should be able to do this and just like, Hey, we have to get this urgent issue out. You might have briefly bypass whatever process you establish, but at at the same time, you know, how to get back on track very quickly.
Thanks, Charlotte.
And then the last thing is in Again, I was talking about figuring out, like, be able to iterate and transform your process as you define it. It's not just do it once, and then it's out there in the wild, and that's it. It's really you have to be open to change. The Salesforce platform is going to change.
What you care about is going to change. The request of what you support will change. So you also need to be able to do that with your process. How do you facilitate new features that come in?
Consider how you would wanna potentially review your process could be on an annual cadence, could be on a quarterly basis. Just figure out how you can constantly keep iteratively improving.
Using, for example, myself would roll out a process where I had I had administrators and developers who had never used Git before Right? So they rolling that out. Like, we had to ramp them up on that, and they were uncomfortable initially.
After everybody got got comfortable with that, Now we're we're starting to look for areas like, how can we do this more efficiently and take care of the things that are now trivial and make it a lot easier to move faster? Constantly keep iterating and reviewing. You might also get feedback from stakeholders that say, you're not releasing fast enough. We wanna release an x amount of faster. Have a way to take that feedback in and consider it. And it's not just your technical team that needs to use it. It's also how your stakeholders need to perceive it on how fast you're moving, and also how those vacation set.
And then I will stop chatting and take any questions at this point anybody has anything top of mind or it neither did or did not answer?
I think we had a a couple of questions, come up in the Q and A. So, an anonymous attendee has asked which project management software that you prefer and how you broadcast the changes that been made?
Yeah.
I I've primarily, the two that I would say, I would lean towards using Asana and Jira, I've used most frequently recently.
I prefer Jira over Asana, but Jira is one of those tools that's very easy to almost get over over, like, Nuance with your data points that you'd enter. It's something that can be done well if done intentionally.
I would lean Jira, especially also with, like, the integrations that it can provide with other tools you can file a lot of, like, linking pull requests directly to a Jira ticket, and it makes things a lot easier to know, like, where use cases come in track to specific code changes.
Does that answer your question?
Hopefully.
And we've had a question from RAS, which is how do you handle deployment of declarative processes with most team members may need to work on the same flow.
It's a great question. So a few ways.
Manual manual changes are not bad changes, which I feel, like, as a could be a common thing that comes through from, like, a DevOps pipeline. You wanna automate everything and everything needs to be deployed. Manual processes should be defined in your pipeline. And sometimes they actually make sense.
Right? Like, sometimes you might have, like, a pick list value chain that needs to go through. And, like, it may make more sense to actually manually change it and use, like, to replace in Salesforce production versus pushing through a pipeline because like, a dipping tool might not know the replacements there. It just treats as net new.
There's for flows in general, there's really two parts to it in my mind.
Having, like, source control, like, get will see the differences. If you have multiple people touching, the same flow, they'll get caught in a merge conflict potentially.
The other thing I would add to that is if it's not super clear, let's say, you have a massive, massive flow that you're trying to work through, communication. Like, that goes a long way too, because you might want to just sit down with whoever else is touching it and try to coordinate changes. If it's a really big flow, you might wanna also have the larger conversation of do we need to revisit this and rearchitect to how this is built?
Those those are probably the three big things that I would do to try to manually handle those. And then deployment, you might have to deploy and activate after. Right? Just be very intentional about gout, you would deploy that and then how you would activate that flow after the fact.
Ross, does that answer your question?
I think so. Unfortunately attendees aren't able to unable to speak and Kind of. I don't know if you wanted to take Nate's question that was more of a overview, which came in on the Q and A.
So size three admin. So your team and then suggestions limitations. Gotcha.
I so, Nate, along with what I was was saying before, I would be intentional, again, about what you care about tracking. It's don't let yourself be overwhelmed by trying to focus on all of Salesforce in general, like all your metadata.
So if you might, like, a simple, like, SFDX project, you might pull in just like Apex classes, objects, profiles, triggers, visual force pages, if you still have some of those in your org, lightning components or aura, like, don't don't try to go swing for defenses on everything. Focus on a small set of things and get through working through a process and then start expanding.
Regarding limitations, A lot of it is gonna be dependent on one. What what's the comfort level of your team and what are they really comfortable with? They don't if you're using something like SFDX, and you have a group of BA's who are have never seen the command line before, don't try to force them into using FDS because you're either gonna frustrate them or you're gonna make it that they don't even wanna use the process, and we'll try to find a way that they don't have to do it, which makes tracking things a lot harder.
So try to, like, consider that as part of the the team foot. You might have some limitations on size, like your org size. It though SFDX is way, way better than some of the old tooling used to be on Salesforce.
But don't worry about having, like, everything get pulled in. You might have some timeouts on the API front, but nothing you should not have anything too too crazy. But if the the t l a d r start small, then expand.
Really, really helpful advice. Thank you. There was another one that it wasn't really a question, but I'm interested to get your thoughts on it from, Alex earlier on. About DevOps Center. They said that they'd tried the DevOps Center last summer, but may although it was maybe a bit too early to try it, their takeaway was that it's not a productivity tool. What are your thoughts on DevOps Center?
So I'm not I'm not just trying to tell the gear set horn here, but one of the things that I prefer to use gear set over DevOps Center right now, like, and kinda how it integrates in is very focused in what it's, like, say remit is. Right? It's not trying to do too much and focus on the entire platform. It's very customized to you.
I don't think DevOps Center is fully ready for enterprise use yet.
I think it's still going through a few things that need to be changed. If that answers the question here, Charlie.
I think that's, yeah, a very, sage advice there.
I don't think that there's any other questions unless I've missed any but obviously, really appreciate that you've, stay stayed a bit later.
So And did you have anything else you wanted to add?
I the only thing I see in the chat is, RAS, you said I kind of asked your question. Is there did you wanna ask a follow-up to that by chance?
RAS, I have a message here if you'd like to ask directly.
Or you might need to unmute your mic yourself. Can you hear me?
Yes. Yeah.
So the the issue is We have a a number of team members. We have, like you said, a few huge flows Sometimes, correction needs to be handled in part of the flow, by one team member.
And then a and a different part by another, then we're going to see a conflict when we deploy right But how do we get back and, fix it, without doing the entire work again on a certain version.
Yep. So, like, two things that would jump at. One, I'm I'm guessing you if you have, in this case here, you have, like, team member one is going through and editing version one. Right? And if team member two is doing different changes they have version two. So there's kind of a conflict there of, like, basically, last one in wins. Right?
Is that correct?
So you're asking for more around, like, guidance on, like, how do you merge those two so you only have a single version that goes up?
Ross?
Sorry.
Yes. Yes. Exactly. Okay. Yeah. So this is where I was I was noting, like, usage of, like, a source of truth in a repository like Git helps a lot because it shows conflicts editing the same file. Because it's it's all a flow, like, a file for that there.
It'll raise it as a conflict, and it's gonna be It might be tricky to actually resolve just by looking at XML, but Yeah. It it's almost like one of the one of the things of, like, a little bit of friction might actually spark a conversation.
Encore enforce your team to have to coordinate on those changes to into a single version.
Loews are tricky because they can get gnarly very fast, that I would take a look at that. If it's something that's constantly being changed. And it's like you you notice that your team is making modifications to it frequently. Let's say, I don't know. Once every two weeks, you have multiple people making changes. Might wanna consider looking at rearchitecting it into sub flows, if possible.
Mhmm. But that that think think about how you measure the amount of time that's being spent to resolve those issues versus how long it would actually take to just re architect it to make it more manageable from a scale standpoint.
Right.
Did I did I answer it?
Yes. Pretty much.
But do you can can you or did you ever is it possible or is it problematic to fix things in the XML itself because I can send some issues coming up. So there there are some ways you could that it can be problematic, but there are ways to protect yourselves from not making it problematic. So you could use, again, using reference and gear set here.
You can use, like, validation CIJobs to actually do status checks that will attempt to build your branch against an org. So you'll have some feedback of, like, this will deploy.
Salesforce Salesforce XML is very fickle.
So if it won't deploy, you'll error quickly before it even hits the org itself. You don't necessarily have to deploy it. You could just validate it.
But I I don't If your team members are comfortable working with the XML and they know what they're doing in terms of, like, balancing those tags out and moving things around, I don't see that there's an issue.
That's the the great thing also about the review process is that you can catch things before it gets too prod. The thing that I would I would I would caution against, not necessarily avoid completely is don't try not to make changes directly to it in production.
Like, have a way that you can track those changes. If manual changes need to happen because it's just, like, you need to coordinate those things. Like, just have a way you can track down how they were done. Like, it could be as simple as, like, bullet points on a Jira ticket.
But having things go through a, like, CI process through git and moving things through, They could be comments on a pull request. They could be commit messages. There's a lot of different ways. They could be comments on that of, like, here. Had to modify these lines to be manual and just leave it as a review comment.
There's a lot more ways to add auditability there that, like, the Salesforce audit log will not show you.
Awesome.
Alright.
Thank you.
Yeah. Thank you. Great question.
I think that is probably all we have time for, unfortunately. So thank you so much for, staying staying behind there, and thank you attending as well.
It's, yeah, been a really interesting session. Lots of great advice to come out, for everyone still that still around, we will be sending out the recording as well because there was lots of great information in there. So I'm sure you didn't have time to take it all down anyway.
Thank you everybody.
Thank you so much, Ray. Bye.
Take care.
