Top Stories from the Microsoft DevOps Community – 2019.10.18

Sasha Rosenbaum

It is the fall conference season, which means that this blog may be brought to you from a different geographical location every week. This week I had the privilege of speaking at All Things Open, and a chance to visit our Raleigh, NC office for the first time ever. Are you participating in any fun events this fall?

To mix things up, this week’s newsletter is featuring a few videos, but we will start with some blogs.

Azure DevOps Migration Tools
Azure DevOps Migration Tools is a community project building tools that allow you to migrate Teams, Backlogs, Tasks, Test Cases, and Plans & Suits from one Project to another in Azure DevOps / TFS both within the same Organization, and between Organizations. It’s been very useful to people in this community who are working with large organizations. The new version v8.3.0 came out a few days ago! It supports restarting the migration, and migrating work items between Team Projects. Huge thanks to all the project contributors!

Azure DevOps – how to package a simple DLL?
Many organizations are starting to move towards internal open source, but the most common way of sharing code across the organization is still via shared libraries. This post from Antti K. Koskela shows a YAML pipeline for building a NuGet package and pushing it to a NuGet feed. Needless to say, the package feed could be hosted on Azure Artifacts. Thank you, Antti!

Tasktop Integration Hub – ServiceNow to Azure DevOps
In many cases, software development bottlenecks are caused by process and communication issues, rather than technical challenges. Tasktop is a product that helps integrate enterprise software delivery tools with operations management tools. This short video features an integration between Service Now and Azure DevOps using Tasktop. The Tasktop Integration Hub provides a two-way sync between Service Now and Work Items in Azure Boards, automatically synchronize IDs, progress statuses, comments, attachments, and other information. So much less process overhead!

Fortify on Demand – New Azure DevOps Features and Functionality
Application security is the top of mind for tech leads and executives alike. Fortify on Demand is a Micro Focus product that offers application security as a service, providing a range of security assessments. This video walks through the integration between Azure DevOps and Fortify on Demand (FOD), kicking off an FOD scan from an Azure Pipeline and verifying that the FOD policy was met before the Build can pass.

Three things to keep in mind when using Azure DevOps Pipelines
When introducing team members to new technical tools, we often focus on step by step instructions and forget the bigger picture. This video from Matthew Shiroma at Nebulaworks dives into three important concepts for setting up Continuous Integration and Continuous Delivery using Azure Pipelines – variable scopes, CI/CD triggers, and Task Groups. Thanks for a great conceptual overview, Matthew!

If you’ve written an article about Azure DevOps or find some great content about DevOps on Azure, please share it with the #AzureDevOps hashtag on Twitter!

5 comments

Discussion is closed. Login to edit/delete existing comments.

  • Ronald Bosma 0

    The NuGet pack and publish example uses nuspec. If you’re using an SDK style project or want to pack and publish both prerelease and release versions of your NuGet package. Have a look at this multi-stage yaml pipeline: https://ronaldbosma.github.io/blog/2019/09/03/using-multi-stage-yaml-pipeline-to-create-and-publish-nuget-packages/

    This example pushes a prerelease version to an Azure DevOps Artifacts feed and a release version to NuGet.org if an approval is given.

    • Bjego 0

      @Ronald Bosma
      I think your blog post isn’t the best approach with building two packages.
      I think you should create just one package and stage it through your “Release” environments – Like “Azure Devops interal” – “Azure Devops internal Release view” – “nuget.org”.

      • Ronald Bosma 0

        Hi Bjoern,

        Thanks for the feedback. Haven’t worked with views in Azure DevOps Artifacts feeds yet. I’ll have a look at your suggestion and see if it fits my needs.

        Ronald

      • Ronald Bosma 0

        Hi Bjoern,

        I tried out Views in the Artifacts feed and it looks interesting. I think it has its pros and cons though.

        If you prefer semantic versioning than the approach I’ve described will do the trick. It will also work if you use a feed, different from an Azure DevOps Artifacts feed, that doesn’t support Views.

        The advantage I see in using Views is that once you’ve tested a Prerelease version you only have to promote it to the Release view. There’s no need to update any package references.
        A concern of mine is that it’s less clear to a consumer in e.g. Visual Studio that you’re working with a prerelease version. Semantic versioning seems to be a better fit for this.
        There also doesn’t seem to be an out-of-the-box way to push or promote a package to the Prerelease view from a yaml pipeline. I did find an extension to promote packages to a certain View though so this is a minor issue.

        All in all I think it depends on your preferences and needs what’s the best way to publish NuGet packages. Since I prefer semantic versioning I’m sticking to my solution for the time being.

        Ronald

    • Antti K. Koskela 0

      Hi Ronald!

      The author of the nuspec article here. You bring up a fair point – I chose nuspec because it made my job of picking up just one, obfuscated DLL really simple, but it’s hardly the only option!

      Of course, if the build produces a lot of different artifacts and does different things with them, a nuspec file can be used in one step without interfering with everything else going on. One such example that comes to mind is a pipeline publishes multiple packages, or maybe a pipeline that builds a solution with helper libraries and a web project, drops the web project as an artefact to be deployed and publishes the NuGet for more general use…

      Anyway, using a nuspec file is just one way to define your NuGet package, but it’s one I hadn’t used before and found it really useful, so I wanted to share it 🙂

      Cheers!

Feedback usabilla icon