Azure pipelines can be created through a GUI or through a YAML file. I will be focusing on the YAML instead of GUI for three main reasons: It is being favored over the GUI Allows to commit the YAML to a source control, thus allowing versioning Re-usability (will cover it in another post) Schema of the YAML file 🔗Microsoft docs has an extensive explanation about the schema and everything that is supported. This is my go-to when I have questions about schema/features.

UPDATE: This “Journey” is on pause, as I’ve switched positions and I currently don’t actively work with Azure Pipelines. 🔗As a first and most broad idea of what a pipeline is, I like to think of it as the filler between developing and delivering your software. A “piece” that aggregates and performs every necessary action/procedure (or at least most of them) to take your code up to the final product (an app, a library, a website, you name it). The most amazing part is that it can be as simple as performing a build to ensure that your code compiles, and grow as your needs, ending up being something like:

In the first part of this series, we have seen how we can setup a self hosted agent (in this case on a Raspberry Pi). To recap, here’s a quick list of things required to do on the target host (this is agnostic to the underlying operating system): Get the latest agent version available (head to the Azure DevOps website > Project settings > Agent Pools > your pool > new agent > download agent) Extract the file Run the config file and specify: Server URL Your PAT Agent pool Agent name Work folder Run the run file or configure as a service. This is fine and easy enough, if you are targeting just one host.