Basic Code Management for the SysAdmin with Azure DevOps
I have a couple of blog posts where I get into how I use VSCode and Git or basics of my Scratch repo technique and those articles can be found here:
The premise being that nowadays almost every admin or engineer I meet has some code tools. Some of these tools they have built themselves. Others are unknowingly "forked" from publicly available code and modified to fit the need of the day. Most of the admins and engineers have another thing in common and that is the lack of source control or version control processes.
As stated before these scripts, programs etc. wind up making their way into production use. You may have heard of 'Infrastructure as Code' before - this isn't quite it probably, but when your infrastructure relies on these "little" scripts for operation, you now have infrastructure dependencies on code. Whether these are for request fulfillment automation or infrastructure operational process automation, these scripts can have a substantial impact if not working correctly.
I am a strong believer that processes should be developed around this code. These processes should involve a very similar process of documenting, testing, reviews and approval as a Change Control Process when the code is used in a production setting. That's what you do for infrastructure applications right..??
Perhaps you work this into your ITIL certified ticketing system. I would 
TLDR:
Here I show a very simple process used to work repos. I use this process myself on everything I develop outside of Scratch.
Quick Terms: (These are my definitions for simplicity)
Repository (Repo):
The place where you keep code that is similar in nature and or requires certain characteristics only found in repos. Things that mainly revolve around access needs of other people and source code organization. Kind of like a super enhanced folder used for source code.
Branch:
This is like a virtual copy of the repo at a point in time so you can make changes to the code without making changes directly to the code itself. The repo master branch holds the production code and you create a branch to add changes before you push them to production (master) branch.
Pull Request:
The process of letting the owner of the source code know you have changes you would like to put into their code. In this case we use it operationally to move code into production.
Goals:
a. Protect production code.
b. Have a very easy to use method of working with SCM repositories so as to enhance code management for Sysadmins without too much complication in process.
Solution:
The solution relies on a simple development branch on the repo that will be set as the default branch. All changes would be made in and to the development branch directly, via local repo push of course. These changes will be committed as you would during development then merged via pull request from the development branch into the master branch. All production code will be deployed from the master branch only.
Let's walk through it…
Here I will use Azure Devops as most of the articles in the past have used Git.
1. Create a new Repository
In this case we are creating a new project for simplicity. We will save Azure Devops Project use discussion for another blog post. This also assumes you have an Azure Devops account and have an Organization as well.
2. Name the repository and give it a description
In this case we are creating a repository to hold scripts used for virtual machine automation. This could be scripts that fulfill self service requests, build machines, install software and agents, integrate into in house management systems. Or it could hold one script.. Whatever you like.
Once the project has been completed you will be placed into the overview page.
3. Navigate to the Repos applet.
4. Initialize the repository with a README
5. Create a development (devel) branch
6. Name the branch and leave the defaults
7. Click on the Manage Repositories form the Bread Crumbs dropdown
8. Expand out the repository and branches
9. Set the development (devel) branch as the default branch
10. Browse to the policies page on the master branch
11. Set the policies to require pull requests and protect the branch
In this case the settings will allow me to merge my own code into production. This may not be the desired state for your process. Change these settings as necessary to fit your needs. Save changes.
12. Clone your repo local.. We will clone into VSCode.
13. Make changes and push your code to the repo.
Here we simply make changes to the README file to get the point across.
14. From the SC applet in VSCode type in a commit message and commit the change with the check.
15. Verify the devel branch and synchronize changes from the bottom left of VSCode.
Now you simply do that until you are ready to push you change to production. This is done very easily from the Azure Devops Repos applet in the Pull Request button.
Pull Request
You don't have to move your code to the master branch immediately of course. You would do this only when you have tested the code to satisfaction and the development of the fix or feature is complete and ready to be pushed to the production code.
1.Issue a Pull Request
2.Change the Pull Request to go from devel into master.
On this same page you can review the changes you are selecting for the Pull Request.
3. Review them and select create
Changes are shown at the bottom
Normally, here, you would tie some process or add reviewers or the project could have default reviewers. Bottom line the Pull Request is reviewed by the master branch owner (this is me in this instance) and approved and merged.
Review the Pull Request at your leisure and explore the features of the Pull Request review process. Commits and Files are usually where I look first.
4. Approve the Pull Request
5. Complete the Pull Request
If you did not set the devel branch as default the delete option is on by default so be careful.
You should get a completed. Now your code is in production
Check the master branch for the changes. Now your code can be deployed to production from the master branch.
All of what you have just done is fully documented, audit-able and fully revertible.
Look for more topics on SCM and VCS! Enjoy!