<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CI/CD on Andreas' Blog</title><link>https://blog.anoff.io/tags/ci/cd/</link><description>Recent content in CI/CD on Andreas' Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 17 Oct 2019 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.anoff.io/tags/ci/cd/index.xml" rel="self" type="application/rss+xml"/><item><title>Building autoscaling CI infrastructure with Azure Kubernetes</title><link>https://blog.anoff.io/2019-10-autoscaling-ci-agent-with-azure-kubernetes/</link><pubDate>Thu, 17 Oct 2019 00:00:00 +0000</pubDate><guid>https://blog.anoff.io/2019-10-autoscaling-ci-agent-with-azure-kubernetes/</guid><description>&lt;p&gt;Ever wanted to create a build agent factory where you do not have to care about how many build agents you need at a given point?
With this post I want to share my experience setting up a dedicated CI runner infrastructure with the Azure + Pipelines ecosystem.
The main features of the solution are automated scaling, ephemeral build agents, docker based environments, minimal operation responsible and strong pay-per-use billing concepts.
Basic knowledge of &lt;code&gt;Docker&lt;/code&gt; and &lt;code&gt;Kubernetes&lt;/code&gt; should exists - you should know what they are.&lt;/p&gt;</description></item><item><title>Migrating to Azure Pipelines</title><link>https://blog.anoff.io/2019-08-24-drone-ci-travis-ci-to-azure-pipelines/</link><pubDate>Sat, 24 Aug 2019 00:00:00 +0000</pubDate><guid>https://blog.anoff.io/2019-08-24-drone-ci-travis-ci-to-azure-pipelines/</guid><description>&lt;p&gt;Beginning of the year I switched my blogs build chain from Travis CI to &lt;a href="https://drone.io/"&gt;drone CI&lt;/a&gt;.
Due to some tasks with Azure DevOps at work I wanted to test how good it fits my private projects.
In this post I will NOT tell you how to set up your pipelines project because Microsoft has &lt;a href="https://docs.microsoft.com/en-us/azure/devops/pipelines/create-first-pipeline?view=azure-devops&amp;amp;tabs=tfs-2018-2"&gt;great docs&lt;/a&gt; for that.
Instead this post will cover how to best put your build workflow into a pipeline specification.
In addition I will cover the necessary steps to migrate existing CI/CD workloads from Travis and drone to Azure Pipelines.&lt;/p&gt;</description></item><item><title>Continuous Vitae - Auto built and git versioned CV</title><link>https://blog.anoff.io/2019-04-08-cv-continuous-vitae/</link><pubDate>Mon, 08 Apr 2019 00:00:00 +0000</pubDate><guid>https://blog.anoff.io/2019-04-08-cv-continuous-vitae/</guid><description>&lt;p&gt;Versioning your CV is important.
One traditional approach is to date it whenever you send it out.
I chose to present my CV on my &lt;a href="https://anoff.io"&gt;website&lt;/a&gt; and host it on GitHub.
In this blog post I want to explain how I set up continuous integration pipeline for building my CV that automatically injects a unique version into each build.
This method is applicable for anyone choosing to ascii-based CV - in my case LaTeX.
You also need some basic knowledge of &lt;code&gt;git&lt;/code&gt;, &lt;code&gt;Docker&lt;/code&gt; and CI services like &lt;code&gt;Drone&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>Hosting Gitea and Drone with Docker</title><link>https://blog.anoff.io/2019-03-24-self-hosted-gitea-drone/</link><pubDate>Sun, 24 Mar 2019 00:00:00 +0000</pubDate><guid>https://blog.anoff.io/2019-03-24-self-hosted-gitea-drone/</guid><description>&lt;p&gt;This post will walk you through setting up a self hosted git based continuous integration environment on a two machine setup - assuming you already have two virtual machines at your disposal.
Using &lt;a href="%7Bgitea-url%7D"&gt;&lt;em&gt;&lt;strong&gt;Gitea&lt;/strong&gt;&lt;/em&gt;*&lt;/a&gt; for git hosting and contribution management and &lt;a href="%7Bdrone-url%7D"&gt;&lt;strong&gt;&lt;strong&gt;Drone&lt;/strong&gt;&lt;/strong&gt;&lt;/a&gt; for docker-based build jobs, this will guide you through creating &lt;strong&gt;docker-compose&lt;/strong&gt;* files as well as configuring the individual services and getting &lt;em&gt;&lt;strong&gt;SSL certificates&lt;/strong&gt;&lt;/em&gt; via &lt;a href="%7Btraefik-url%7D"&gt;&lt;em&gt;&lt;strong&gt;traefik&lt;/strong&gt;&lt;/em&gt;&lt;/a&gt;.
Docker and docker-compose knowledge is required for this tutorial. It mostly focuses on the correct configuration of all the services at play here and not explaining their basic functionality.&lt;/p&gt;</description></item><item><title>GitLab CI/CD for GitHub</title><link>https://blog.anoff.io/2018-03-30-gitlab-ci-for-github/</link><pubDate>Fri, 30 Mar 2018 00:00:00 +0000</pubDate><guid>https://blog.anoff.io/2018-03-30-gitlab-ci-for-github/</guid><description>&lt;p&gt;When creating a git project that you want to share with others you traditionally had the choice between GitHub with its huge community and tons of integrations, GitLab with a great overall dev experience from issues to one of the best CI/CD solutions out there and BitBucket being one of the friends you have since kindergarten. My personal decision was to host all my personal projects on &lt;a href="https://github.com/anoff"&gt;🦑 GitHub&lt;/a&gt;. For projects that need CI/CD I tinkered around with &lt;a href="https://travis-ci.org/"&gt;👷‍ Travis CI&lt;/a&gt; and &lt;a href="https://circleci.com/"&gt;🅾️ Circle CI&lt;/a&gt; on top of GitHub.&lt;/p&gt;</description></item></channel></rss>