With this post I want to share a lazy and a hacky way for finding the Azure DevOps Project Id of any project in your Azure DevOps Organization.
It can feel a bit daunting to start using Azure DevOps API. But what most folks are not aware of is that data retrieval API’s can be queried using
your favorite browser.
To get the Project Id we can do this with the projects LIST and GET API’s.
The task of explaining concepts of the Microsoft Azure Cloud befalls to us Cloud consultants. Usually we have to explain these concepts to stakeholders with varying levels of technical expertise. So using a simple analogy often helps to clarify complex ideas. In this post I want to share my favorite analogy. The house analogy! I am sure that I am not the first to come up with this analogy, however if you like my variation, feel free to use it in your own presentations or discussions.
Back in 2022 I wrote a blog post I am in your pipeline reading all your secrets!
about how secrets can be leaked in Azure Pipelines.
I think it’s time to offset that blog post and have a look at how compliance of all pipelines in a single Azure DevOps Project
can be achieved. This is done by using a feature called Pipeline Decorators
.
In most organizations there are certain required compliance and security policies. For example; to be compliant with corporate policies a static code analysis tool must to be executed on all pipelines before executing the actual pipeline tasks. This is where pipeline decorators come in, pipeline authors don’t need to remember to add that step. We as Azure DevOps Organization owners create a decorator that automatically injects the step into all pipelines during their runtime. Ensuring on an Azure DevOps Organization level that all pipelines are compliant with our organization’s policies.
While this post is outside of my usual topics, I would like to share a solution for an error message which returns just a single search result on Google. I want to share it because it took me some time to figure out what was going on. So in case someone else runs into this issue this post might be helpful.
It all started after the network team updated the network to a new public IP. Right after this change all users started to get the error message 400 Bad Request. QWNjZXNzIHRvIE91dGxvb2sgb24gdGhlIHdlYiBoYXMgYmVlbiBibG9ja2VkIGJ5 IHlvdXIgb3JnYW5pemF0aW9uLiA8QlI+PEJSPkNsaWNrIDxhIGhyZWY9Ii9vd2Ev bG9nb2ZmLm93YSI+aGVyZTwvYT4gdG8gc2lnbiBvdXQu (Base64) when trying to access Outlook on the web (OWA) in Microsoft 365.
In my previous post 🚀 Azure DevOps Container Jobs: When Microsoft and Self-Hosted Agents meet, It’s the Best of Both Worlds! 🌐🛠️ you where able experience Azure DevOps container jobs. In this post I am delivering on my promise and explain set-by-step how to build and use your own container with Azure DevOps Container Jobs. Buckle up, and let’s get started!
Lets start by having a look at the target set-up.
Did you know that you can run your Azure DevOps pipeline jobs in a container? It’s a great way to combine the benefits of Microsoft Hosted Agents and Self-Hosted Agents. In this post, I will explain what Azure DevOps Container Jobs are and how you can use them to your advantage. But first, a recap of Microsoft Hosted Agents and Self-Hosted Agents.
Microsoft Hosted Agents are a type of agent in Azure DevOps that are hosted and managed by Microsoft. These agents are pre-configured with certain software depending upon the type of agent (Windows, macOS, or Linux) which can run jobs targeting different platforms. With Microsoft Hosted Agents you trade off control for convenience as they are an excellent choice if you need to quickly scale your operations without worrying about the underlying infrastructure management.
