Top Stories from the Microsoft DevOps Community – 2019.09.27
Whether or not you are an optimist, many jobs in technology teach you to anticipate and protect against the worst-case scenario. In this week’s community stories, we learn more about the importance of automated testing and the perils of edge cases in Site Reliability Engineering. Let’s get started!
Terraform on Microsoft Azure – Part 6: Continuous Integration using Docker and Azure Pipeline
Terraform is rapidly growing in popularity, and we’ve featured Terraform integrations a number of times in this newsletter. Testing your infrastructure-as-code, however, is still relatively difficult. In this blog post (part of a series), Julien Corioland walks us through the process of testing the Terraform code using Terratest in Azure Pipelines. Thank you Julien!
Cypress in Azure DevOps Pipeline for Fast, Easy and Reliable Test Automation
Speaking of testing frameworks, this article features the integration between Azure Pipelines and Cypress, a JavaScript-based testing framework providing an end-to-end testing experience for modern web applications. It is certainly important to not just deliver great features, but also make sure that your UX is working as expected!
Developing a PySpark Application – Creating a CI Build
while While we are on the topic of Continuous Integration, we might as well discuss a third very different programming language and use case. In this post, (part of a series) Simon D’Morias walks through configuring CI for a PySpark application built for DataBricks, using Azure Pipelines. Thank you Simon for sharing your expertise!
Global DevOps Bootcamp 2019 – Keynote
I was aware that a 2012 Azure outage was due to a certificate issue, but I never knew it was caused by an edge-case! In this recording of the keynote from the Global DevOps Bootcamp 2019 Niall Murphy, a leading site reliability engineer at Microsoft and the co-author of the The Site Reliability Workbook talks about the professional pessimism of the SRE, and everything that could go wrong when running a production applications in distributed computing environments. Backed by examples of some astonishing outages!
Azure DevOps Demo Generator is now open source
Typically, we don’t feature our own blog on this newsletter, but I had to make an exception for this one. The Azure DevOps Demo Generator is now Open Source! This project has been an example of the power of cross-team collaboration and volunteer contribution from its very beginning. It has enabled a quicker path to learning and implementing POCs of common use cases of Azure DevOps, simplifying the onboarding experience. And now it is going to allow for an even broader impact, as it can be leveraged by organizations outside Microsoft. A huge thank you to my teammates – Dave McKinstry, for all the hard work that went into the open-sourcing, and Sachin Raj, for making the demo generator happen!
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!
Light
Dark
1 comment
Still no Top Story about build histories – including source control labeling/tagging – being deleted due to the bungled “streamlining” feature? I have software in production now that I cant make a hotfix for because I can’t reliably identify what code made the programs currently in production. This is affecting lots of people and some are finding out maybe a bit too late.
I’ve had a support case open for weeks and that support resource and their supervisor are getting nothing but promises of yet another feature that will solve the problem, except that it doesn’t. This new feature (“retain x builds per branch”) was clearly designed or thought up by someone who does not understand elementary components and relationships involved with code branches and build services. It wrongly assumes that there is only ever going to be one build per branch, ever, which while it is an ideal goal is not actually how it can works out IRL. If anything, the feature should be “retain x builds per build definition” with possibly some defaults at the org level and overrides available at the build def level. And it should be hard to delete a version control label or tag. Note I’ve not mentioned Release pipelines because Its clear that the two things are being incorrectly conflated. The process to create the release-able artifact is not the process (or processes) that distribute that artifact. Had I created release pipeline invocations for each and every build, then that would have preserved history for some of the build artifacts, but I’m not creating release pipelines for things like nuget package builds, or things that cannot be deployed automatically yet and thus would not have a release pipeline.
I still dont get how this kind of thing can even happen. The first page one would go to for the new feature was broken. Should have been a big red flag. Please try to not box your customers into a specific corner, and try to do better with the quality of released products. .