DevOps 101_ Git for Admins

Share with

Description

With businesses looking to find more comprehensive ways to unlock team productivity and product reliability, decision makers are increasingly drawn to Git-based version control. From increased peer collaboration to improved quality control and deployment success, Git is an invaluable tool that’s guaranteed to boost any business.

Catch up on this session with one of Gearset’s DevOps Advocates (and former Account Executive) Jack McCurdy, and you’ll leave knowing how:

To explain what Git is Understand how Git works Understand the benefits of using Git And whether or not it’s worth it for your or your team.

Learn more:

Related videos:

Transcript

Alright. Well, a very warm welcome to all of you today. Thank you very much for taking the time to to join me today, on DevOps one zero one, Git for admins.

Really pleased to see, all of you, attention to the call here.

We have a we have a chat box there as well. Like any webinar, I'm sure everybody's had our fair share of those over the last year or so and is getting used to using Zoom and what have you. So please do just hop in the chat box, talk to each other, or feel free to send messages to, the panelists, myself.

One of my colleagues, Ben, is Ben is here as well, to help field some of your questions. And, without further ado, let's get going. So, welcome to the session.

My name is Jack McCurdy. I am one of the account executives, at Gearset.

I've worked with Gearset for the last two years or so, and I've typically, I work with, anybody in an organization that has, something to do with Salesforce and its development. So, everybody from, the admins and the developers to Salesforce product managers and, CTOs, etcetera, who are looking to get the most value, out of their Salesforce investment and are looking at, their development practices to do that.

So that's what I spent the last kinda two years or so doing and continue to do.

I really enjoy it. Really enjoy being part of, the ecosystem here. So, hopefully, I can impart some basic knowledge on, those few that are less familiar with, Git and how it works, and start to explain, some of the benefits, of what using Git will do, for you and your team and potentially your organization.

So on that topic, objectives, what are we looking to be able to achieve this session, and what do we wanna do, at the end of this, kind of hour or so?

So you wanna be able to explain what Git is.

Hopefully, everybody will, everybody will be able to understand, or at least explain in layman's terms, what Git is by the end of this session, understand broadly speaking how it works and how it operates.

I wanna understand, some of the core benefits or the core benefits of using Git.

And then maybe we might, at the end, be able to think about making a decision or investigate further whether investing in Git is something that would be worth it for you, and your teams if you don't already. Or if you do already and looking to leverage it a little bit further, hopefully, this might light the fire, for you to do that.

So to get started, we need to think about what is Git. So I'm sure if Git or, version control has come, to anybody's minds or anybody's thought streams, recently, they've probably gone to Google and typed in what is Git or what is version control.

Now according to the Oracle Wikipedia, Git is a distributed version control system for tracking changes in any set of files originally designed for coordinating work among programmers cooperating on source code during software development.

Now as an admin, it's fairly easy to probably look something like this. When I first started, working at Gearset and, getting involved in the ecosystem, this was what I thought, absolutely when I first started. So this is a common response.

So if we start to unpack the statement, then we can start to understand a little bit more about, what it is. So the first reason here that might cause a little bit of confusion maybe or, need some explaining is, distributed version control system.

So version control is a system that records changes to a file or a set of files over time so that you can recall specific versions later. Distributive means that it can be accessed from a central server and locally. So that means that, most Git providers are hosted in the cloud there. So you can access them from everywhere, and you can download, what is on Git onto your local machines as well, which is fairly common, in in development practices for working, on that source code.

Files.

So files in this context are the individually separated blocks of features that make up your org's configuration.

So in Git, you will have, for example, your account object, which will be a file in Git.

So in the big scheme of things there in that description, it's for tracking changes to those files over time as you change, and manipulate your org, add new features, etcetera, based on your user stories and your end users' requirements. Programmers, this is fairly self explanatory. This is us, your fellow admins, developers, architects, and myself.

And then our source code. So when we traditionally think of, Git and software development, we're traditionally thinking, in those traditional software development terms. So your source code being, the code behind the application that we're using.

Most things that we do declarative or otherwise can live as code, and the declarative changes that we are used to making, live in Git as XML. So although we will be making the majority of our changes, if we're admins using clicks not code, whether that be flows or, additions to those account objects, opportunity objects, whatever it might be, that will live and can live in Git as XML.

So there it is, with those kind of keywords. So, hopefully, that gives you a little bit more context, to what our Oracle Wikipedia, says about it.

But doesn't really give us too much, too much of an understanding. That's kind of just the basics, to get us started there.

In simple terms, like that explanation said, Git is for allowing us to track changes over time to the metadata in the org that we, are working with and the features that we're developing. So think of your org as a living, breathing, entity.

So when we make changes to our sandbox and look at promoting that to production, those those things are living. Those things are being interacted with, all the time.

So what Git will allow us to do if we develop through Git, it will allow us to track those changes, rather than the org just being the living, breathing entity that it is, ever changing without any, real history there to back us up or see what's changed, over time.

Every change in Git is annotatable, accounted for, and can be approved, through that process as well.

So things like why you made a change, who made the change, and links to your ALM.

So if you use Jira or Asana or any of those issue tracking softwares as well, you can add all the context in the world to any particular feature, why a field was added, why a field was removed, etcetera. All of that can be tied together, and give you plenty of context for why those changes happened, not just that that is how it is now.

Access anywhere.

So this means if you change your machines or what have you, your org and its configuration can be accessed from anywhere.

And working in collaboration with your colleagues, you are all able to work on your features, and you can do that from any place that you would like to do that, as well as well as locally, to, develop things, in in a secure environment where things aren't gonna be changing, under your feet, as well.

So that's what we mean by, the distributed system, that I was mentioning earlier.

So to get get a bit more of an understanding, we we need to have a bit of an idea about how it works and, what we do with it.

So to get started, we need one of these. So this is a fairly common response when, you ask, somebody that's not familiar, what is Git? They might reply GitHub or GitLab or one of the other, Git providers that we are familiar with. So GitHub and its friends are Git based version control systems.

Each one of these, systems will have its own UI, but, ultimately, they do the same thing and allow us to do the same thing. Who you will ultimately choose if you do go down this route will depend on your preference, really, and subject to security reviews and things like that.

You may you may find that software developers elsewhere in your organization already use one of these.

So it's fairly common, to have, your software developers developing other features functionality for maybe your product, elsewhere in the organization. So you already may be set up. It'd be worth asking, your team there.

So in using Git, we need to extract the metadata from our work first. So this is the first main difference between traditional software development and Salesforce development.

Is in the traditional software development, you work on your source code, you develop it, test it, etcetera, and then you would ship it, and then that would be the application itself.

If we come back to what I've said earlier about Salesforce being a living or living organism, so to speak, we need to be able to extract that metadata and that XML from our org first. So we need to use a mechanism to get that XML out of our org, and, traditionally, that's done with a CLI tool. Ants, you might be familiar with or have heard developers speaking about, Salesforce deployment tool or the Salesforce DXCLI.

And then that can be quite a challenge for admins, especially when you're first getting used to, all these new concepts, using a command line interface. That's all new, and the learning curve can be quite steep. So that's why tools like Gearset exist to help flatten that learning curve, whilst we interact with those systems.

So we need to extract the metadata from our org first, and, we do that by using, an API. So Salesforce has, a bunch of APIs that allows us to extract metadata from our org and pull it down and start, to store that in our repositories and start to work with that, in a safe way.

So I mentioned the word repository there.

In our repository, we work branches. So our repository is the place that we store our, our files, and our folders that make up our org structure.

So a GitHub environment may have multiple repositories for multiple different applications or projects, and our Salesforce org will live, in our repository, for example.

And then we work with branches, so that, we can work with that safely whilst we undertake our development. And you will typically have a main branch or historically potential master branch as well, and that is the source of truth for your org. So this will, be, as near to production as it quite possibly can be. In some instances, it might be slightly ahead of what production looks like because of how you've developed it, or it might be slightly behind depending on how you're using Git and if you're just using it as a backup for your Salesforce production environment.

We have feature branches as well. So this is where you will be working on your tickets or your user stories, feature requests, and things like that. And feature branches will typically be stemmed off, another branch potentially straight, from main or master or from a developer branch, but this is where you'll work on your isolated features.

And depending on the size and complexity of your company and its structure and your release process, you may well have other branches, that match your org environment set up as well. So potentially a UAT branch or a staging branch or a release branch if you're working in, two week sprints or something along those lines. This is also fairly common.

When we're working in those branches, we commit or to save our changes in that branch before we merge it back into, master or or the main branch or the release branch, wherever that might be. So to commit those changes, you change the thing that it is you need to change in your org, in your developer environment, that new fields, whatever it might be, and then you push that field from your org into that branch that you're working with.

If that feature is complete, you will then open a pull request for that branch to then be merged, back into its source.

And that is how we get new features from our orgs into our branches and then back down into, the branch that we need to release to production from.

And this is what a simple user story might look like here.

So if I get my pointer here, we have our master branch here. So this is the main branch here. This is what's going to be most aligned to production, which we will likely release from, to production at some point.

What we do when we start working, with version control and to make sure that we have the most up to date metadata in our developer environments is we create a feature branch from master here.

So this feature branch will be an exact copy of what's been in master, but now we're working in isolation, and now we're working an environment that's completely safe to work in. And we're not altering code, or mess data that's directly in our production environments or in our production branch. We're just gonna be looking with we're just gonna be working with something that's isolated, and this will allow us not to overwrite any other changes that we're working with. So what we do is we update our dev sandbox, from that feature branch and make sure that we've got the most upstate metadata in that sandbox. Then we can safely make some changes here and commit those or save those changes back into the branch. Say you save it once and then go back and do some more changes in the dev sandbox and then save it again, and then that feature is going to be complete.

You may well be able to hear some background noise.

I have a small child running around the house, so apologies if you can hear that, as we're going through here.

But once we're finished with our changes and committed those back down, into the feature branch, we open our pull request, and merge that bank into master ready for that to be released.

Thanks, Ethan.

If we're working with a colleague or working with another member for our team, another admin or developer, it might look something like this instead.

So this is showing you how we can work together, whilst doing things safely.

So we both have a master branch here and have both created feature branches to work independently of each other, and this means we can both make our changes safely from our sandboxes, and, push those back in, to to the master branch.

So you see here, I'm the admin. I've created my feature branch. I'm pushing, my changes, committing those back into that branch, emerging that back back in.

And at the same time, my developer colleague here is doing some, potentially, Apex work here, working with his integrated development environment and pushing those changes into his feature branch, opening his PR, merging that back into master.

And then with this diagram, you can see a little bit more of the release cycle as well. So we have a continuous integration job here kicking off things to staging for its testing. We also have an optional deployment box here for going to UAT, and then finally your production package ready for release at this stage as well.

So this is this is how you interact with, with these different people.

And you can see here that working in isolation, is really useful for making sure that you're not changing things under under each other's feet.

So I'm working here, in my admin sandbox and safely in my branch, and doing the things that I need to do, as well as my developer here working in their branch, doing the things they need to do, and what we're doing isn't interrupting each other, and we can all do that safely.

The most common thing that we get asked, as, as in this space is what about our, what about our merge merge conflicts, and how that comes up. And these will still need to be resolved at some point, and Git will help you identify those.

If my admin if if I, as an admin here, have made a change to the same file or, change for same change to the same file that my developer has. When my developer tries to merge this feature in here, that will tell us.

But what Git will allow us to do is it will show us that, and then what we'll be able to do is make a decision of how we best proceed and whose feature is more relevant to move forward with based on, our businesses or users' requirements.

And this all comes back to being able to annotate and, be able to explain all the changes as they're being made and link it back out to our ALM and things like that. So we've got loads of context here to allow us to make, the correct decisions.

So what are the benefits of working with version control here? So we can collaborate better with our colleagues.

So what I mentioned there about identifying conflicts is is the big one. So this means if we do happen to touch the same feature, say we both touch the same field on an account object as we, are working with the flow or something along those lines, Git will highlight those things to us and help us identify what the best thing, to do is. That will still require your human intervention to, understand what the best thing to do is, but with Git, you will have, all of that context there as well because all your change documentation is in one place.

So the links to your ALM, integrate with Jira, etcetera, you can have links to all of those kind of tickets and all those kind of things, Salesforce cases, whatever it might be that you're using.

You can you can do that, and all that context is there to allow you to make that decision.

You'll improve your reliability as well. So if something is, going to go wrong, from a resilience perspective, you have basically a backup of everything that you've done. So say you do a release and something needs to be reverted or changed back to how it was, it has systematically got all of those changes in there for you. So you can go back to a version that was, most appropriate, and you've got a reliability factor built in there as well if you do start using more branches so you can safely test new features, in isolation as well safely.

And those are the those are the main things that we need to look up, in terms of benefits.

We have a question, in the q and a for feature branches. In a group environment, how do you handle working on the same feature?

So so this is an this is an interesting one.

So typically, what you might see, and it will depend on the team size and the size of the feature, what you would typically see is have a for a larger project, have a project branch, or a large feature branch and then a feature branch off the feature branch and different members of the team work on different bits, and handle any, handle and resolve any merge conflicts as you work on something, slice by slice and features off the feature. When that feature is complete and ready to merge back into your release branch or, your main branch there, you can do that. So that is probably what you will most likely see, in that scenario.

And, ultimately, all of the the reason that you're probably looking at something like Git is because you probably heard the words CI or CD thrown around quite a lot. And Git is the start of the journey. It's the first part, of this this journey that we like to like to go on, as businesses and towards digital transformation.

Git is probably gonna be the starting place for you, which is why it gets talked about all the time, why Salesforce is releasing DevOps center themselves, all of these things.

So we are probably towards this lower end, I would say, of this scale. Judging by the talk, hopefully, you're most likely probably sitting around this beginner potentially looking towards that, that novice stage.

So what Git will enable, we're gonna start looking at getting some of our metadata into version control, getting familiar with the basics, of version control before advancing to more accelerated DevOps processes. So using Git as the absolute source of truth for their development, and start to do some automated deployments, automated testing, and those kind of things. But the base of all of good DevOps practices, will be successful implementation, and working, with Git.

So what does this all look like in practice?

So I appreciate that I've been speaking, a little bit, and, there's been a lot of a lot of kinda theoretical.

So I thought it'd be a good idea to, just give you a quick walk through, of what this, what this will look like.

So if I take a look, at my Salesforce environment so this is, one of my development environments. So I've got a ticket that has come in, and I need to update some help text, for a checkbox on an opportunity. Turns out the salespeople aren't quite so sure, about what's, it's going to be used for.

So if I navigate to my object manager, look for my opportunity, fields and relationships.

We have our active opportunity, here as well.

So this is the checkbox that we that we want to change.

So I'm going to edit this and name my help desk sales.

You should check this if the opportunity is active. Now this is a pretty nonsense checkbox as most sales organizations are gonna know if they're active, that that their opportunity is active or not because it'll probably be closed woner or be closed lost, or what have you.

But for the sake of this, we'll show you how this works.

So I'm gonna save this, and that is some work that I now need, to commit or save, into my feature branch, before I safely merge it back into, my, main branch, for release to my production environment.

So to do that, I am gonna use Gearset, to make my life a little bit easier here.

So I've been working in my developer two environment, I believe this one is.

I need to push this down, into my GitHub, branch. So I'm going to make sure I create my new branch from main here.

I'm gonna call this help help text update and create that branch, and then just run a quick comparison to be able to pick up and select that change here.

So I'm use obviously using Gearset here, as well. This would usually or more traditionally be done, with the command line interface, and Git commands, to create that branch and pull down that metadata and update that metadata, as required. So, but you can see here I'm using gear set, which makes this a little bit little bit easier and not have, to to understand how to use CLI or any of those commands. So we can see this is the active opportunity here, and this is the inline help text, that we've got that's been added. So I want to select that to be committed, move to the next stage.

And then here is where we can start to think about, some of that documentation. So if we're committing this, to this branch, we can pop in what we call a commit message. So every time you save, what is created is a commit message, which will allow you to give context in the repository and on this file of why it's been changed and what it's there for. So if we say this is ticket number one, updated as requested by the sales team.

Simple help text.

And I'm gonna now push that, into, push that into that branch that I've just, that I've just spun up.

So that's all done, and now that's that's in there, and that's living in that that branch, now successfully. So say at the same time, I am also, one of my colleagues, but I've also gone to look at updating this text field at the same time. There's been a breakdown of communication, and I independently, of of this update, want to go and do this, in my other environment.

So if I log in with, my other credentials here, hopefully, this will be quite familiar for some of you bouncing between, lots of different orgs.

I get myself logged in and, update update that same help text.

Get down to my opportunity.

Fields and relationships.

Active opportunity.

We can see here in my my other developer environment, we haven't got, the, we haven't got the help text.

Sandeep, the cool app for password keeping was one password, which we use here.

So if I update my help text, we can pop in sales team. This is self explanatory.

I'm having a bit of a bad day, and I'm I'm going to going to call it this.

And I can't spell this evening apparently. So hit save, and that's all ready to now be pushed into my other feature branch.

So I'm going to now, use gear set to do exactly the same thing that I've just done, and push this into another feature branch, because with Git, we're obviously working in isolation, from each other to make these changes. So developer one, which is where we're at here, create my new branch from the main branch, help text is great.

Great branch.

Run my comparison here, and get ready to update the help text, for this branch. So, hopefully, you're all following me, so far in what I've been doing. This is where we're gonna so when we hop into git in a minute moment, you'll be able to see, for both of those branches, the comments that I've added, and what we will eventually see, is a merge conflict and how you decide. You'll be able to see how you decide how to move forward with, what makes the most sense. So we can see here the new updated text here. Sales team, this is self explanatory. We've got nothing living on this side, as yet.

Move to the next stage and the next stage.

And updated help text in box as requested.

Hope this helps.

And remember, this was ticket one we decided.

So now we've deployed that, to that branch or committed it to to this branch, should I say say to speak in, in the Git terms.

So if we view this, on on GitHub, we can see here that we've got our two branches, now created in in GitHub.

So I'm using GitHub here. The this is the one that we like to use.

So we now have the option to view both these branches, compare those, and create those, all important pull requests, to allow us to look at, look at these these things.

So help text is great. That's there. I had to push one minute ago and then help text updated.

And you can see here from, my repository, you can see here this is where both of these things see updated. So you can see all of the history from every file that I've changed, over time depending on what's been interacted with here. You can see here what I've, what I've been doing.

If I go down to, my opportunity here, you can see updated help docs as requested. Hope this has helps. That's ticket one. That's, the most recent, most recent update.

So if I create the pull request, I'm gonna do that from gear set for the help text updated branch.

We create the pull request.

This is new help text as per sales team request.

Please approve.

So we create the pull request.

That's successfully created in GitHub, and that's all good to go.

Typically, you might have a review process here as well. So depending on, what's, what your release cycle is or, what's, depending on what your release cycle is or, how strict you are in terms of your release management and who can approve certain things. It's fairly common for, a developer or administrator not to be able to, approve pull requests for their own features, for example, just so it's got another second eyes of it. You can see all the notes that we've got here, updated help box, why the, PR has been opened.

And you can see, here as well that my branch has has a conflict.

So you can see here that I am now going to resolve the conflict here, and we can see here from, from the most conflict that's been identified for us. Help text is great. So help team, so the help text here, sales team is self explanatory from help text is great. Isn't so great, but you can also see here, sales, you should check if this opportunity is active, which is slightly more helpful. If we wanted to, because we've got all that context and help from, the the branches and the commit messages, we can make a decision on what, we want to keep here.

So once we've identified this, we can make a decision, and then we can delete these lines as requested.

And we're gonna keep the most the most relevant and the most helpful, the most helpful text there.

I need to mark this as resolved, and now we can commit the merge.

And what we've now got is those branches combined, merge the pull request, and now we're all done. So now the latest sections in my release cycle can now happen, as we saw in that diagram earlier.

So this is all fantastic.

Git has now got all these changes, and we now have a history of what happened, so that we can go back to, go back to developing happily and developing in isolation.

Another great thing here as well, is if we bounce back to our repository and look at these branches, you can see here with our merged, our merged branch here. If we wanted to, if something wasn't quite right, the sales team doesn't want that anymore, then we it's easy for us to go back to, go back to these merges, and we can look at reverting, these pull requests as well so that we can change those back easily. And you've got that whole history that you can go back to, at any time.

So this is really what Git is all about. It's all about that collaboration, having everything in one place, so that you can see, how things have changed over time and have that safety to go back to, as as needed.

So, hopefully, that gives you a little bit more of a more of an idea about, what Git is all about and why it's important and why it's needed. And, obviously, one of those key enablers, as you're thinking about your processes, I'm sure some of you that are on this call, right now already are thinking about this or already doing parts of this, is how you accelerate and take that to the next step.

So this is really the really the place you need to start. Yeah. I know, and I appreciate it probably all looks, a little bit alien as does any new system.

I appreciate that I've, dropped in a couple of, couple of things that you might not be familiar or are a little bit alien to you. But if you're still intimidated, or things don't make sense or you simply want to know how you can level up in the DevOps space, I recommend you check out DevOps Launchpad.

So DevOps Launchpad is a bit like Trailhead. So it's a free platform that anybody can sign up for, and you can learn the fundamentals of Git. You can learn the fundamentals of DevOps and complete courses on there, that will really help your understanding if, Git and, CICD or, accelerating your DevOps pipelines is something that you've got planned.

And then go and check out DevOps Launchpad. So that's, just dev dev ops launchpad dot com, and you can, take and you can, and you can get get your fill get your fill there, basically.

Troy has asked, what happens if someone makes a change in a higher Salesforce environment for the start scenario you just demoed? So that is a great question, and it will depend on, what happens in in your release cycle.

So this is this is if you think about it, this way, this is a classic case of, a code clobbering, I suppose, you could call it, or the typical overwriting of, features that you would see when you use a change set. So if it was made updating that help text and somebody had changed it in a higher environment, when I did a change set and when I did a change set, I would just overwrite, that with the my most up to date version, and that would get lost, for example. So that's what would happen normally. If you're using a Git based approach and that in that method, that method of working, usually, you would find that main branch is gonna be your source of truth.

So, if you were deploying to production and that was the process and somebody had changed something in production directly, for example, when you go to deploy from your main branch to production, you would see, at that point, whatever the if you're using just a command line interface and just going to use, a deployment script, then that will overwrite the change like it would for, like it would for a change set, for example.

Or if you are using more intelligent tool like GearSet, it will show you those differences, before you overwrite those changes. But, ultimately, that's what it's all about. That using using Git means and enforcing a process like this means that if you are operating as you're supposed to in your two separate branches, you will see that that conflict is going to arise, before it causes, causes that happening and, being overwritten.

The Tim is asking, is there a list of Salesforce messages that plays well with Git? I have noticed issues in the past with various types of metadata as well as some minor changes in XML performed by Salesforce over time, in our production environment.

So, the the long and short of it is most metadata can live in Git fairly happily, providing that it is supported by Salesforce's metadata API.

Some metadata types are tricky trickier than others to handle at terms of a list of things that plays nice versus not playing nice, I am not a hundred percent a hundred percent sure that I can give you a definitive list of things that don't play nice, but you tend to see, but you tend to see people, or some company organizations struggling with slightly bigger bigger file types, like profiles, for example, things that aren't so, aren't so easily handled because of, the way they are and what what they are.

Another one of the another one of the benefits there of using something like Git that can semantically break these things down into small component parts, then that that can help. So if, like, those changes that I showed you, I just updated the custom field rather than updating the whole object, and, it got stitched into the XML properly. So so so to to roundabout answer your question, then some of it is is trickier than others, I think you'll find.

But, ultimately, most of it can live in there, fairly happily, without too much intervention providing it supported by Salesforce's metadata API.

Yeah. Absolutely, Tim. So, a lot of, a lot of companies choose to start with the more traditional things. So the developers with their Apex classes, tend to start there, and you're quite right, your object settings, things like that to and gradually build that over time, as you get more familiar and, more comfortable, with using Git.

Ernie asked, do you have tips, suggestions for incorporating managed packages, into Git? So if your managed package, has customizations, then then sure.

We tend to if it's one of those managed packages that doesn't require too much customization, then there isn't too much need for it to, to live there or be deployed from Git when it can just be just just download it into your developer environment and check that it works as you're expecting it, then just do the same in production. It's gonna save you some hassle. But if you have customizations, that you can make to those managed packages, then, sure. Those can live in there too.

Somebody anonymous has asked, can GearSet support tagging?

What do you mean by tagging? Anonymous.

Hopefully, you can still hear me. I haven't lost you.

So so are you referring to, like, tagging tagging lines of codes or commenting on them? Or Maybe misconstruing this completely.

Okay. Sure. Sure. So so Gearset won't, automatically, like, update or or create tags yet is the is the answer is the answer to that one.

Alright.

Like I was saying, DevOps Launchpad, they're a great great little platform there, especially if you're first started getting out or maybe if you've been around the block and just want to have a nice shiny shiny badge and certificate like Trailhead offers, then have a look at DevOps Launchpad, and you'll see, a bunch of content there. Those diagrams that were in this presentation, for the the Git workflow and the feature development as well as some advanced workflows, to get your teeth stuck into, live there as well.

A whole host of useful content. It is written by us, and produced by us. So there's content on GearSet in there as well if you happen to be GearSet customers, and that's all free, learning platform for you to get your get your head around, our app as well as, the fundamental basics of DevOps. So I would a hundred percent recommend getting in there.

Yeah, Veronica. So in that short demo that that I was doing there, I made some declarative changes in two developer environments, and pushed those changes or committed those into Git feature branches, and then, merged those feature branches to to to the main, branch resolving a merge conflict at that time.

So you still use your, declarative changes and and to complete your declarative changes in, in your sandbox's developer environment, so wherever that might be. And you just push those into, into those and commit those into those feature branches, in isolation before then doing a release, from your main branch out out to production.

So that's the intended workflow there.

That answer your question?

Great. If you have any questions, any more questions, then then then keep them coming.

Or if you want to talk about, any any of this privately, then, you can drop me an email, jack m at gearset dot com, or visit us at gearset dot com for a ton of other, white papers and resources, as well. I'm a massive fan of LinkedIn as well, so you'll definitely find me over there. If you send me, emails at eleven o'clock at night, I will probably be there to answer them.

So you can get you can get me there, but happy to have any other questions from anybody, that has them now, in the next ten minutes or so.