It can be easy for developers when working alone to overlook using a code repository. Especially, if like me, they started out just hacking things together to get a task done quickly. This impulse to just check a task off of our list can motivate us to overlook tasks like testing and checking in changes. It may cost a little extra time up front, but it will save you a lot of time later when things go awry.
I recall working on project many years ago. It was a small ASP.NET web application that I had created for in-house use and was the only one to work on it. While I had deployed the app to a web server in our server room, I had not chosen to use a code repository like Azure DevOps or GitHub. The pressure to meet deadlines led me to just muscle through overlooking this much needed step. So when I lost my local copy of the code (hard drive failure or something), I had no copy of the code to retrieve.
In some shops, you might use other forms of file system or OS backup to protect from this issue, which certainly is better than what I had done. However, using a code repository enables a number of additional features beyond disaster recovery. You will document your changes along the way, helping with troubleshooting issues later. You can compare (diff) different versions to help discover that typo that is giving you all that trouble. You can also setup a new device to work on your code quickly.
For this article, we are going to take the .NET ScriptLink project that we have been working on and commit our code changes to Azure DevOps.
What You Will Need
To follow this process, you will need the following:
- Visual Studio 2019
- A solution to commit/publish. (see previous articles)
- Azure DevOps Services
This is free for the first 5 users. If you are already an Office 365 customer, you can use your Work or school account to create this to help keep it secure.
Add Our Solution to Source Control
You may have noticed through this series that Visual Studio was offering to Add to Source Control in the lower right of the interface.
Let’s do that.
- Open our ScriptLink solution in Visual Studio.
- Select Add to Source Control in the lower right of the user interface.
- Select Git.
You will notice that when complete, you should see the interface change.
This is showing that there are 2 unpushed commits and 0 pending changes.
Push Our Code to Azure DevOps Services
We should now have the Team Explorer tab selected with various options to publish our code. If not, select Team Explorer and then select Sync.
- Under Azure DevOps, select Publish Git Repo.
- Select the account to login to Azure DevOps with. You may need to login, if not logged in yet.
- Select the organization, if not already selected.
- Confirm the Repository name.
- Select Publish Repository.
When this process is completed, you should see a prompt reporting that the solution was pushed and the unpublished commits should now show 0 in the bottom right.
Commit a Change
Ok. Let’s make a change. Our ICommand interface is potentially in conflict with the System.Windows.Input.ICommand interface and could cause confusion for other developers working on our project. So let’s rename it to IRunScriptCommand.
- Select Solution Explorer.
- Right-click on our ICommand.cs file and select Rename.
- Set name to IRunScriptCommand.cs and press Enter.
- When prompted to rename all references, select Yes.
- We should now see pending changes.
- Next, let’s run our Unit Tests and verify that all of the tests pass.
- If all went well everything should have passed.
- Next, we will commit our change.
- Select the pending commit at the bottom-right of the UI or select Test Explorer->Changes.
- Describe the change made and select Commit All.
- Once committed, you should see there is now 1 unpublished commit and 0 pending changes.
- Now let’s select the unpublished commit count in the bottom right or select Sync in the Team Explorer.
- Select sync to push the changes to our Azure DevOps repo.
That’s it. We have now successfully created our Azure DevOps repository, pushed our solution to it, and pushed a subsequent change to it.
What Next?
Azure DevOps is just one option for managing your solution’s code. Next week, we will look at this same process using GitHub instead. This is another popular option especially for open source projects. After that, we will be looking at deployment options for our ScriptLink solutions.
I hope you are finding this series interesting and helpful. Thanks for reading.
Rarely Simple 
You must be logged in to post a comment.