This Rocks

This Rocks

No. This isn't about my absolute favorite band, but LinkedIn has the option for a photo and I thought why not. After all, this solves a problem for me that I wanted to solve for a while.

The issue

I have a solution that does a lot of things and they do these things very generically. OK.. So I am going to slightly change what I work on as to not give anything away there.. But let's say I make widgets of Thingamajiggers and Thingamabobs and Loopedieloos. I have a single api that handles the creation of each where the creation is kicked off generically through something being placed into a queue. There is a lot of shared stuff behind the scenes to make these items. But every time you need to make an update to Thingamajiggers, you're touching the same code as the others. And what happens when you add a Jinglingjangos? I'll also add that the single api to do the building of these things uses an api through Azure App Services.

Solution

First of all, we need to separate out the Thingamajiggers from the Thingamabobs and Loopedieloos or whatever fun things comes along. And we'll use a similar platform. We'll use an Azure function with a queue based trigger for each.. That means at least 2 Azure function apps per thing we're creating. That is so we can have an active active scenario with our functions using multiple regions.. (I am totally oversimplifying it here). The fun part was how do we separate out these things in a usable way such that a different team can take your behind the scenes stuff to create Jinglingjangos or whatever it may be? And how do we do so in a way that works within the constraints that all code is deployed through ADO and we want versioning and all that good stuff?

I started looking at git submodules to store our shared code and tried that and didn't like the experience at all.. Too messy and too much to setup.

Da da da da!!! This is C# so Nuget packages fit well. We can create a nuget package and ADO has this thing called Artifacts that can host Nuget as well as similar things. So how to get this shared code into Nuget? I couldn't find much that showed me the full solution so I did some digging..

Create a .nuspec file and place it into your project.

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
        <id>sharedThingy</id>
        <version>1.1.0</version>
        <authors>Shared Thingy Creator</authors>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>Thingy Plugins Shared Library</description>
    </metadata>
    <files>
        <file src="bin\Release\netcoreapp3.1\*.dll" target="lib" />
    </files>
</package>

And then let's go to ADO and look for Artifacts in your project and click on Create feed. You give it a name and set who can see it, etc.

No alt text provided for this image

And then go over to your pipeline and add a dotnet pack and a NuGet push. You set the path to the nuspec file and all that good stuff.. It's all straightforward stuff.

No alt text provided for this image

And for the Nuget push step, there is a Target Feed and you'll set that to the name of the artifact you created.

No alt text provided for this image


After the pipeline runs, you can go back to the Artifact you setup and there is a link to "Connect to Feed". Click on that and then click on Visual Studio. It will give you instructions that I won't include a screenshot of, but it tells you how to add the nuget path to your environment and then selecting that nuget option will show you the new nuget package.

And now, Jinglingjangos can take your nuget package and create their thing. Obviously, there is a bit more to this, but I don't want to get you lost in the details so I am trying to keep it simple.

Hopefully that all made sense. I just wanted to throw something together real quick (like 15 minutes to demonstrate). I know I benefit from the trails other people walk. And keep rocking!


To view or add a comment, sign in

More articles by Chris Cottrell

Explore content categories