Greetings all my name is jason culler, I'm a support operations manager here at git lab and today we're going to cover the change management process for zendesk macros. I'm going to share my screen and talk through this. um We like to do all our change management, fours and desk macros through the zendesk macros repo.

The location will vary based on if it's federal or global into the us federal or the global instance. The process itself might vary a little bit depending on which is which, but, generally speaking, it's going to follow the same kind of process. It will start with someone submitting an issue or an mr merge request to make a change from that point. A support operations person will review it.

If it's an issue we'll generate the changes, make the make a merge request associated with it. um If it's a merge request we'll review the changes. um Testing is an interesting topic for macros, because they're generally not destructive. We uh we tend not to do a lot of testing around them other than kind of, of course, stuff. Looking over the ammo file, making sure yeah will it sink? Do we see any typos, et cetera, et cetera?

However, we leave this the decision to each support, ops, team member who is reviewing the request itself. They might look at it and say ooh. This looks tricky. I should go test. This make sure it's not going to cause issues. They might see something decide. Oh I'm you know, I I think I see a better way to do what this person is wanting, so we get to test it.

It's really going to depend on what the support operations engineer themselves decides now from there um they'll kind of go into the making sure the merge request is a good place, get it where it needs to be. After doing so, they will then you know they'll then uh basically have another support, ops, team member review. It make sure they approve the changes um depending on the actual macro. There might be somebody who, in support like support managers right now, but this could change at any moment.

It could be somebody in billing or security um someone there might decide to. We might have certain files that the decision is a support manager should also review the changes. That's because the messaging that's being used could be important change, workflows, etc, etc. We have a code owner's file in this repo.

This is what it looks like right now again, this could change at any point. If changes are needed to it, you just make a merge request and kind of go through the same change management process.

But after you know, if somebody from support like a sport manager has to review and they approve it and another support, op team member has reviewed it at that point. We're going to implement, we would just merge the request, make sure the change is applied to zendesk correctly, and that's all that's really required for it. Beyond that point, it would be on the requester to announce it if an announcement is needed for this change, um it's going to vary based on exactly what the macro is kind of doing.

Now. An important note is because macros categorizations is determined by the file name itself.

We have a lot of different folders in here to kind of help keep the repo organized as an example we have stuff like we have a support folder and that there's a support, ops, folder, and in that there's you know uh the stuff for, like the shared org shared organization macro we sent, which sends all this information to a customer cc's all the support, ops, team, you'll notice, the name of this macro support, support, ops, confirm request for shared organization.

If you look up at the top here for the file path, it's in the folder support and the photo support ops. Then the file is confirm, request for shared organization dot. Here this. uh This styling is very important. You want this in place. We do not want this changing, so uh try to make sure it aligns with that. Another big thing to kind of check for is make sure it's a dot, gamma file y, a m l, not y m l. That's a common mistake, also make sure the file's in the correct folder.

Often we have people put it in the root directory and you can certainly make commit your files to be in this root directory, but they will not sync to zendesk in that way. That's all. There really is to change management. uh You know, review documentation, workflows and such reach out to your fellow support, ops, team members, if you need more clarification or help with it, I hope you found this educational and I look forward to seeing you in the next video.