Azure DevOps is a fantastic product and a really great way to put all the standard structure for a project into a single, easy to use location. Which is great for projects that you know are projects: new project at work … DevOps; new client for your development team … DevOps; shared development across multiple team members … DevOps. But what about your more standard development: I’ve got a random idea that I want to try in a simple Console Application … DevOps? I just want to write a quick bit of code to read iTunes Library XML and extract some play count information … DevOps? Those are more likely just a bit of code on your computer; might be in a development folder; might even be on your desktop. There isn’t a need for all the creation work of a new project for something that might be run once, sorts all your files into sub-folders, and never run again. However sometimes these little developments start to grow and become useful and now you have something running that people (or just yourself) are using … how do you go from “on my desktop in a folder” to “in Azure DevOps” when you didn’t start out in Azure DevOps?
The Transition Process Overview
The process to go from something just on a PC to that same something in the cloud with Azure DevOps to use all the features and benefits is straight forward:
- Review Code for Security, Credentials, and Sensitive Information
- Create an Azure DevOps Project
- Transfer Code Base from Local to Azure DevOps
- Setup Azure DevOps for On-Going Development
Review Code for Security, Credentials and Sensitive Information
The first step in transition is that this code is going into the cloud and that you are opening the ability to share this code with other team members or potentially external parties; you might not, this might still be all for just yourself, but even still you don’t know what the future brings and code history is code history so best to remove any sensitive information (passwords, connection details, resources, etc…) before you transition to Azure DevOps
Standard: Transition to appsettings.json File
The most common scenario is a couple of passwords (maybe twitter or email credentials) and a connection string or two. In local development these can be in startup variables; for this transition you can move them to an appsettings.json file and then exclude that file from Azure DevOps so others can access the code, but not the sensitive / personal information.
Create an appsettings.json file
In your project right click, create new file, json file and take your data from the code an put into that appsettings.json file.
{
"Twitter": {
"ConsumerKey": "my-key-value",
"ConsumerSecret": "my-secret-value",
"AccessToken": "my-access-token-value",
"AccessSecret": "my-access-secret-value"
},
"ConnectionStrings": {
"DatabaseConnectionString": "connection-string-value"
}
}Install NuGet Microsoft.Extensions.Configuration.Json
Use NuGet to install Microsoft.Extensions.Configuration.Json this will enable you to access the values in your appsettings.json file
Create Configuration Object to Read Values
To access the values in the appsettings.json file you can utilise the ConfigurationBuilder to pull values in a couple of different methods.
Standard Creation of Configuration Builder: used in Azure Functions and other development options
var configuration = new ConfigurationBuilder().AddJsonFile("appsettings.json", optional: true, reloadOnChange: true).AddEnvironmentVariables().Build();Alternate Creation of Configuration Builder: in some cases the appsettings file might not be in the most obtainable location; and to access there is a SetBasePath option to enable that in the ConfigurationBuilder; to handle different scenarios (Windows Services in particular) I’ve written a “GetAppSettingsPath” method
/// <summary>
/// Determine base path (and confirm appsettings.json exists in that location)
/// </summary>
/// <returns></returns>
public static string GetAppSettingsPath()
{
var appsettingsFilename = "appsettings.json";
// first pass use AppDomain.CurrentDomain.BaseDirectory as the basePath
var basePath = AppDomain.CurrentDomain.BaseDirectory;
var appsettingsFilePath = Path.Combine(basePath, appsettingsFilename);
if (!File.Exists(appsettingsFilePath))
{
// if not able to find basePath then check Directory.GetCurrentDirectory as the base path
basePath = Directory.GetCurrentDirectory();
appsettingsFilePath = Path.Combine(basePath, appsettingsFilename);
if (!File.Exists(appsettingsFilePath))
{
// unable to find appsettings.json; throw exception to that point
throw new Exception($"Unable to find file {appsettingsFilename} using BaseDirectory or GetCurrentDirectory");
}
}
return basePath;
}Then using that method create your configuration
var configurationBuilder = new ConfigurationBuilder().SetBasePath(Utilities.GetAppSettingsPath()).AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
var configuration = configurationBuilder.Build();Read Values from Appsettings.Json File
Now that the configuration has been created you can read your settings in and use them in your application.
GetValue Method
var codeKey = configuration.GetValue<string>("CodeKey");Direct Access Method
var codeKey = configuration["CodeKey"];Direct Access Method with Nested JSON (see Twitter Example Above)
var twitterConsumerKey = configuration["Twitter:ConsumerKey"];Note: if using this method with an Azure Function you need only to name the application setting in Azure with the colon and it will work for both the .json file and the Azure Function deployment
Connection String
var databaseConnectionString = configuration.GetConnectionString("DatabaseConnectionString");Create an Azure DevOps Project
Microsoft has documented this better than I would; follow the create-project steps provided here:
https://docs.microsoft.com/en-us/azure/devops/organizations/projects/create-project?view=azure-devops&tabs=preview-page
Transfer Code Base from Local to Azure DevOps
There are a number of methods and techniques to get local code files into an Azure DevOps code repository (repo); I find that most of them are a bit more complex than they need to be and try and do a bit too much for the user. I take a more direct approach, creating a bank repo on the Azure DevOps project; pulling that repo down and transitioning code base locally before confirming code, committing and pushing changes to the cloud repo.
- In Azure DevOps navigate to Repos and then Files
- Select the “Initialize main branch with a README or gitignore option
- Select VisualStudio .getignore
- Click “Initialize”
- Record the URL of the Repo generated (this is your “Repository Location”)
- Optional: if you want to keep code in the location you have in your local computer: rename the current location (add “-original” or similar) as we want to create that target location via this process
- Open Visual Studio
- Select Clone a repository
- Enter your “Repository Location”
- Enter the “desired code location” (this will now download the README and .gitignore created in the initialise process)
- Close Visual Studio
- Copy code to the “desired code location”
- Open .gitignore and add an entry for appsettings.json
- Open Visual Studio and select your project (at this point your code is still local and you’ll see a large number of pending commits; this is your chance to review and finalise before your first push to DevOps)
- Commit code and push to DevOps
You’ve now transitioned your local code to Azure DevOps; you didn’t have the overhead of creating a DevOps project before you started your development; but in a couple minutes you’ve been able to get to that point on a project that now has this need.
Setup Azure DevOps for On-Going Development
Now that you’re in Azure DevOps, take full advantage of the environment; start populating your backlog with features and stories; create branches to work on those stories and pull requests to take that development and put it into your master source control.
In part II we’ll look at further next steps with Azure DevOps and how to take immediate advantage of the new environment you’ve now setup.
Tidemark @ RisingTide.Tech 