Description
Wondering how you can automate your Salesforce release process with finesse? Catch up with Busayo Longe, Product Manager at Gearset who’ll show you how you can accelerate your Salesforce delivery with a powerful DevOps platform. Learn the tips, tricks, and key concepts that’ll make you successful in delivering value to your end-users like never before!
Learn more:
Transcript
Hello, everyone. Welcome. Welcome.
So, I think it's probably we've got most of the attendees have, joined now. So I'm just gonna hand over to Basayo who is going to talk you through this webinar today.
Over to you, Busayo.
Thanks, Michelle.
Hi, everyone.
My name is Busayo. I work with a large teams group at Gareset, and I'm one of the PM's, product managers, looking after our pipeline's products.
Here's a brief overview of what we're gonna be going through, today.
We're going to talk a bit about the state of just the admin's experience in Salesforce, and then we'll talk about, some best practice for admin admins, and then we will go into, a very brief, pipelines demo.
To start off, here are some quotes, from Reddit that was pulled where admins have talked about how the struggle today and what they struggle with. I imagine that this resonates with a lot of us today.
The the role of the admin in in Salesforce has expanded over time. Initially focused on user management and basic configuration.
The admin role now often involves data management, security oversight, and even aspects of development, but there hasn't been a corresponding increase in resources and support.
Recent surveys and and studies have shown that the admin reports feeling overwhelmed due to the scope of their responsibilities and the combination of routine task, project work, and emergency fixes can often lead to feeling overwhelmed.
And in many instances, organizations don't leverage the best tools, leaving admins to handle an increasing number of manual tasks. And this accumulation can lead to feeling overwhelmed.
The role of the admin has been impacted by how Salesforce itself has evolved over time. While DevOps has introduced a battle tested way of working, adoption in Salesforce is still on the rise. And for many organizations yet to adopt DevOps, working in Salesforce can often mean that you're working in separate sandboxes or environments and often unaware of what others are doing. And so overwriting someone's work is quite common.
You would also possibly work, with multiple environments with considerable difficulty in maintaining consistency across different sales force environment environments.
Also, configuration drifts across aux can be quite common with no way to ensure that environment are in sync and which can lead to deployment failures and generally unpredictable behavior.
Due to, lack of automation, release cycles can be slow, making it difficult to, to respond to a change request. And so you probably have very little insight to what's going on or even those dependencies. And, generally, your work isn't interconnected with others.
DevOps for people who might not be very familiar, term was coined from software development and operations. And it's essentially a set of tools and processes that helps, team build, test, and release software quickly and efficiently.
It's been around for quite some time, long before we started adopting it in Salesforce.
And some benefits that it brings to to the workflow, are the introduction of CICD, which is continuous integration and continuous delivery or development, which has made it possible to automate quite a lot of, minor processes.
It's also created a cost that way to work across different roles in Salesforce.
And so working in Salesforce, can become a lot more collaborative.
And so, you know, dependencies are a lot more visible, and it's also starting to introduce a manual an automated testing.
So, essentially, we're looking to, go for, we're looking for a workflow that moves from separate silos and independent work by each role on the team to a much more inclusive workflow where, everyone feels like, they're involved in the process. Everyone is everyone knows where the the stories have progressed to and how better to have other people's work.
As of that, there is much better communication across the teams.
A DevOps pipeline, has been lacking to our assembly line. It focuses on automating and linking the various tasks tied up by the different teams, such as continuous integration by developers, test automation by testers, code deployment by release managers, and generally ensures that the final product, in this case, the deployment, meets the business requirements.
But this can look different for teams based on the level of adoption and choice of tooling.
In practice, adopting DevOps can look like a a series of magic incantations for an admin who's not familiar with it.
And that can often mean having to learn Git, which is very different from how you work. It also means picking up a lot of new concepts around version control, branching, pull request, merge conflicts, and many more times.
However, in reality, there's they are really mostly, a bunch of steps in in the workflow similar to, the car assembly exam and the example we gave. Some of the recommendations we'll be making are tools admins can use, which abstracts the more technical portions of DevOps, and and that could look like this.
There are few tools on the market, and, this is just one example. But I do work on CareSet. And so an example will be CareSet pipelines.
And here's an example of what that could look like, which we'll get into, shortly.
Each box in this on on this page, is where work needs to go, and that can be done with an org to org, deployment using team sets today.
These are the different stages, teams could be on the DevOps adoption journey. And as an admin, you're likely to be in an organization at one of these stages.
Whether you're still adopting using change sets, in your organization or adopting the most recommended practices, you're likely to experience some challenges, especially when you're working with developers in the same workflow.
And, here are some reasons why, that can be.
One of the biggest hurdles, to cross is the culture shifts to DevOps, and many companies struggle to shift from how they've typically worked to more collaborative and integrated approach that DevOps requires.
This can mean that many people within the organization still work in fragmented ways.
Developers tend to be exposed to DevOps practices naturally in their work as it's been around for a while.
However, admins still prefer to work declaratively.
Additionally, many tools introduce quite complex, concepts of admins and require additional training.
The end result is that, while a number of companies are adopting DevOps, there's still a gap between admins and developers' work.
We've put together a few scenarios here, mostly to, talk through what the the experience of an admin, would be based on what kind of team you're working on or where you are on your DevOps journey. And that's just to walk up to talking about what this looks like, in in Pipelines.
I've heard an admin compare working with Change Sets to try to play Jenga blindfolded. We were one wrong move, and everything just comes crashing down.
Here, I imagine that I'm an admin in the team that's just starting to adopt DevOps, and I'm still quite used to, working with change sets.
If each other is unlikely to face difficulty in tracking, changes across my deployment, not knowing, when I've done something I shouldn't have done as no one is reviewing my changes and having very little visibility into what has been deployed.
A few things that could help, to consider if you are, expressing this today. If you are limited to using change sets, then, I would say you need to focus on planning a diversion, break down your task into bite sized pieces, and map out your deployment plan. I'd say you can think of this as your game plan to avoid surprises when when, you're making your deployments.
Creating checklist of all the components you want to deploy can also help you, as it can reduce the chances of incomplete deployments.
You also want to look out for dependencies, and since change sites don't automatically include those, you want to manually, add related components.
If you can install, extensions, in your work, then a Chrome extension like Salesforce inspector or Change dot helper can help you, surface those dependencies.
And if you are new to using Change dot, then the device is always just that small, as this makes deployment easier to manage and debug and reduces the chances of disruptive issues occurring.
In the medium to long term, I'd say that getting familiar with DevOps and and more of the DevOps concept will bring a lot of benefits to to your work, and I would say getting familiar with this is probably more sustainable in your long term.
However, if you do have, if you don't have restrictions on tooling, you can consider using, software like. Again, the exam the other examples here, this is just the one I'm most familiar with. It can help with packaging and dependencies, and also change tracking as it brings a lot of visibility into what is being deployed.
In this example here that I'm gonna play shortly, I'm an admin that needs to do an aux twelve deployment, which I can also do using change set.
But, I just wanted to show how tooling can start to make it visible, more visible here.
Here, I'm connecting my Salesforce, source and target inbox, and I'm able to select specific changes I want to deploy and see what this looks like, in the source and in the target.
The field allows to see what is new, what has changed, and what has been deleted, and when I'm comparing this was on target.
Additionally, I can start to see missing dependencies. I'm gonna I'm I'm I'm putting things up, putting through.
And, eventually, it gives me the detailed list of the validated and deployed components.
Again, this is just one example, of how to embed visibility into what is going on in your Octo deployment.
In this scenario, I'm an admin who's struggling in a DevOps, process where it's been adopted. I have to work in a really fast paced environment, which means that a lot of change requests I need to process.
I also have to work in a pipeline, with automated testing and deployment in place.
And and beyond DevOps, I have to factor in security, into how I work.
It's also very likely that I'm working in a system that has existed for, for long periods of time.
As an admin on this team, I'd say that, you really need to increase DevOps as it guarantees that you can work faster and a lot more effectively.
A new friendly tool, would increase your piece of work and reduce the chances of making mistakes. It also helps you to understand the impact of your work and also others on the on on what you're doing.
One thing to add here is that a good tool, we help manage metadata types like flows and lacking web pages without needing to learn XML, which is something admins also struggle with.
Another recommendation is to set up some monitoring and alerts to stay on top of deployment and events to know when, this have failed or to know when something requires attention.
Lastly, I'd say that you should also embrace tools that support, static code analysis, vulnerabilities scanning, and also compliance checks.
So now we will go into a, very, quick pipelines demo.
Just checking that back homes are fine.
So in this, pipeline right. So each of these boxes, represents a CI job.
You can think of this CI job as a connection between where your work stays, which is your repository, and where and your Salesforce box, which would be UAT, or main in this case.
On this team that I'm on, I work with, Tom, and both of us have our sandbox connected to, this pipeline.
Now before coming here, I've created a new flow in Salesforce and also the lightning web web page, and I want to take that change into my pipeline.
At at this point, I would need to then come in here to, put a change in. And this process, is generally, defined as committing your change. Essentially, I would come here, see a see how the user stories have been assigned to me and select one of them, and this automatically creates a branch name for me.
You can think of a branch as the folder for all the work you're doing.
So, essentially, you are taking the work in yours, in your org and then committing to this branch, which is how you put it into the pipeline.
I will now start a comparison here.
Here, as I've shown before, we're able to see all the changes that are have, have been pulled. So I guess I can see what has changed in my sandbox since the last change I made to production.
And I can see the new change and deleted items here.
But more broadly to call out here is, this is the flow that I I'm looking to work with. And we can see using Jess's flow visualizer, that that looks just how I expect it to be rendered and isn't just XML that as an admin, I might struggle to understand.
This is quite similar with the, Lightning, page where, the change is being rendered here as I would want or I started to show, in the final, environment.
And so I will select my flow and, take that through to commit it.
This is where we'd potentially surface any dependency that you might be missing that you haven't selected as you're taking this change through, but nothing that shows up here. I'll go here to my pre department somewhere.
Now, essentially, what I've done is I've saved, the work I have done in Salesforce into this branch, which essentially is a holder for it.
You can do this as many times as you want to. Let's say, for instance, this flow that I'm working on then add a label change or something else was added. All I need to do is essentially commit more changes and so can think of committing as a saving the work into the branch. And I did this as many times as I want to, before I'm ready to move that change forward.
The next thing we have here is, an integration environment.
This essentially would be where, my work and Tom's work, would be merged into the pipeline. And it does a couple of things.
One example is that it's possible that, myself and Tom have made changes to the same fields, in which case, a conflict will arise, which is referred to as a merge conflict. And in that situation, you would need to, pick the change that you would, like to take forward.
That will look a little like this in a tool in a tool like your asset.
So we will fetch the, conflicts, which shouldn't take long. Not sure why it's taken a few more times. Yeah. So that looks at this like this where, the switch changes will be surfaced and then you're able to select, the one that you, would like or the version you like for each of this, and then mark that as resolved and then commit that merge.
I should also add that if someone else has worked in my sandbox and sort of had this clashing change, it would show up similarly, here in GESET.
Now, my change that I made to the flow is still right here in my sandbox, and I would want to move it here. The process of, requesting that that change will move from my sandbox into the next environment is generally referred to as creating a pull request. And, in that situation, you can easily do that, in a tool that brings sort of all the tools together.
Now that pull request has been created, and, we would see that job here very shortly.
This is really just a quick overview into what working in the pipeline will feel like and the benefit it brings to you, like, being able to resolve conflict and also being able to visualize, the different, types that you are working within Salesforce.
Once this change here has been, accepted or there's conflict here, I'll just pick another one, and I can promote that change into the next environment, which is your team.
Here, I can go ahead and test it. And if everything looks good, I can continue to promote it forward until I get to Maine where, I can, add it to the final version.
Besides today, I would say that the question with around admins and and how admins work is an ongoing one. And and, I would say that over time, we need to talk about more success allocation and also, having clear definitions for that for this role.
If you do wanna pick up or learn a bit more concepts on DevOps or pipelines, there are free courses at DevOps multiply dot com that you can pick up and then take. However, if you do wanna try any of the things I've shown here, for free, you can start at guest dot com. Thank you very much.
Great. Thank you so much, Posayo.
We do have a question. We have two questions, actually, and we have a bit of time.
So perhaps you can answer these for us.
Yeah.
So the first question is, can you set permissions on who can promote?
Yes. Definitely. And so there are different permission levels.
I might be able to I don't think I can get to that in in the call. But, yes, you can set permissions on who can promote. And that generally not just for noncompromise, but over and over with activities and pipelines.
And that generally gives you good control over who's able to do what and make that make what is happening a lot more predictable.
Great. Thank you.
And the other question that we had through is, do you have to have a release pipeline to be doing DevOps?
Actually, I'll say no. And the best practice is not to even start with the release pipelines if you're new to doing DevOps.
We actually have seen that the kernel adoption is usually the the recommendation here, because there's quite a bit involved. You need you need to change the way you work, which are more cultural shifts. And you need to gradually improve your process until the point where, you work up into using pipelines.
So once that can be adopting Git where you can start to present control your metadata, and then maybe move on from there, but I wouldn't say that going from where you are to a release pipeline is even recommended. I'll say starting small and moving up is generally, the best practice.
Great. Thank you. We have one final one through in the q and a, which is what are the differences between Salesforce DevOps center and Gearset?
I'd say that, Gearset itself is, it brings a couple of, benefits that maybe you might not find at DevOps center. A lot of it brings, collaboration, in, just on your team, but also in our able to visualize the different method that you deploy. An example that I gave here is, the, flow visualizer or even, the lightning web pages where you're able to visualize them a lot better, which brings more transparency that you, wouldn't actually find in the dev ops center.
Great. Thank you.
So I think we'll probably wrap up soon, with the time being what it is.
But, yeah, I would love to say thank you to you, Paseo, and to everybody for joining today.
Hopefully, this session was helpful for you.
As I said before, we'll send an email out to everybody who signed up so you can jump into more of these these topics again.
And if you have any questions, just get in touch with us via our website. You can send us an email. We've got a in app chat that is live and very quick responses there.
So, yeah, we're happy to help if there are any follow-up questions. And, yeah, have a wonderful rest of your day. Thank you so much.
