Software, Design, Architecture and Whatever Else
One of my favorite features of Azure DevOps is its package management feature where you can publish NuGet packages to your own organization’s feed. Packages in your feed can be referenced by other projects in the CI/CD pipeline or through Visual Studio. In this walkthrough I’ll give a simple example of how to use it. I’ll assume you’re comfortable with Azure DevOps. If you’re not familiar with the tool see my four-part series on the subject.
If you live in the northern hemisphere like me then this Friday is hibernal or winter solstice. For those of you in the southern hemisphere it will be the summer solstice. Either way happy solstice to all! For those of us in midwinter the Earth’s north pole is at its maximum tilt away from the sun. This means that the apparent height of the sun is at its lowest point in the sky on the winter solstice.
Believe it or not a bunch of people — your friends and neighbors — have no idea what I’m talking about right now. But I suspect you think astronomy is cool or you wouldn’t be reading this right now. So I’m here to help you build an awesome solar calendar in your front yard both to mark the changing of the seasons and to help visualize the sun’s apparent motion across the sky. Your neighbor kids will love it trust me. And it will be fun for you to design and build. After the jump is a photo of the finished product as it looks in the parking strip in front of my house.
I won’t repeat the project home page except to say that if you need good strong security for clients (MVC or otherwise) calling services (micro or otherwise) then this is for you!
Basic authentication middleware is no longer available in Core 2 and I’ve blogged about that before and wrote a SquareWidget.BasicAuth.Core NuGet package. Even with TLS you should probably not use it unless you have no choice. The password goes over the wire in base64 encoding rather than ciphertext, it sits there in the request header for the whole session, the user can cache it permanently in the browser, and anyone on the network can sniff it out before it gets to the web server.
So why do people use basic auth so much? One word: convenience. Developers fall back on the tried and true rather than take the time to do the right thing. So my aim with this middleware is to encapsulate all the goodness of HMAC and keep it dead simple so that the developer has no excuse for not using a more secure algorithm.
This is the introductory post in a four part series walking through the process of creating a project in Visual Studio and building out a complete CI/CD pipeline to get that code into production on Azure using Azure DevOps.
Here’s a rough outline of where I think this series will go. As soon as I have the content ready I’ll link to them from here:
Part 1: Publish to an Azure DevOps Repository
Part 2: Setting up a Build Pipeline in Azure DevOps
Part 3: Setting up a Release Pipeline in Azure DevOps
Part 4: Adding a Database to the Project
A little context… Lately I’ve been using the Eclipse plugin Subversive for source control on my java-based projects, which uses an on-prem SVN server. For C# projects I use the Visual Studio plugin VisualSVN. Back in the old days I used an on-prem TFS server. Before that VSS which I’ll just leave that right there. So I’ve used SVN for many years and I have no complaints about it in particular or concurrent version control systems in general. But this series isn’t about those tools or centralized version control. And it’s not about Git Bash or shelling out to the command line from GitHub Desktop or anything like that. Download the Pro Git book if you want to dive deep into that area.
I’ve also used TFS v1.0 and before that NAnt and then CruiseControl somewhere along the line. Currently my place of work uses TeamCity for builds, NUnit for tests, Octopus for deployments and probably other things like DbUp for database scripting. And I’ve deployed straight to Azure from Visual Studio more times than I can count. But guess what? This series isn’t about any of those things either. In this series I want to help you to take your game up to the next level so that your pipeline to production is fully automated. And I want to keep it as simple as possible. So let’s get started at Part 1.
This is Part 4 in a series on Azure DevOps.
In Part 1 I created a simple web app called WidgetApi. I then put it under source control and pushed it up to an Azure DevOps repo. In Part 2 I configured a build pipeline and made a code change to trigger that build with continuous integration. In Part 3 I set up a release pipeline and deployed our build artifacts to Azure. In this part I’m going to add a database to WidgetApi and use a DACPAC file to bundle database changes for deployment in the release pipeline. Finally, I’ll configure a production environment with an approval process.
