<?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 Sander Knape</title>
    <link>https://sanderknape.com/tags/ci/cd/</link>
    <description>Recent content in Ci/Cd on Sander Knape</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Mon, 03 May 2021 21:03:01 +0200</lastBuildDate>
    <atom:link href="https://sanderknape.com/tags/ci/cd/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Shift left AWS tag enforcement with Terraform and tfsec</title>
      <link>https://sanderknape.com/2021/05/shift-left-aws-tag-enforcement-terraform-tfsec/</link>
      <pubDate>Mon, 03 May 2021 21:03:01 +0200</pubDate>
      <guid>https://sanderknape.com/2021/05/shift-left-aws-tag-enforcement-terraform-tfsec/</guid>
      <description>&lt;p&gt;There are many ways to improve the developer experience of deploying infrastructure into the Cloud. One such method is by shifting left: provide early feedback to shorten the feedback loop and speed up development.&lt;/p&gt;&#xA;&lt;p&gt;When deploying infrastructure into AWS with an infrastructure as code tool such as Terraform, you can validate that code as part of a CI/CD pipeline. A pull request can automatically receive feedback about the configuration of resources, thus enforcing the environment to stay compliant with the organization&amp;rsquo;s policies.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Go crazy with GitHub Actions</title>
      <link>https://sanderknape.com/2021/01/go-crazy-github-actions/</link>
      <pubDate>Wed, 13 Jan 2021 16:32:12 +0200</pubDate>
      <guid>https://sanderknape.com/2021/01/go-crazy-github-actions/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://github.com/features/actions&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;GitHub Actions&lt;/a&gt; is a component of GitHub that allows you to create automated workflows. Through the many different &lt;a href=&#34;https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;events&lt;/a&gt; that can trigger workflows you are free to build whatever automation you want. While the most common use case is building CI/CD pipelines, the possibilities are pretty much endless. Check out this list of &lt;a href=&#34;https://github.com/sdras/awesome-actions&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;awesome actions&lt;/a&gt; to get some inspiration.&lt;/p&gt;&#xA;&lt;p&gt;Having spent quite a bit of time with GitHub Actions in the last few months I came across some features that aren&amp;rsquo;t very well documented. It&amp;rsquo;s therefore very well possible that not everyone is familiar with these capabilities. Let&amp;rsquo;s dive into five neat features that you can go crazy with.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Deploy your pull requests with GitHub Actions and GitHub Deployments</title>
      <link>https://sanderknape.com/2020/05/deploy-pull-requests-github-actions-deployments/</link>
      <pubDate>Wed, 06 May 2020 12:49:31 +0200</pubDate>
      <guid>https://sanderknape.com/2020/05/deploy-pull-requests-github-actions-deployments/</guid>
      <description>&lt;p&gt;Performing (automated) tests on pull requests is a powerful mechanism to reduce the feedback loop on code changes. Known as &lt;a href=&#34;https://en.wikipedia.org/wiki/Shift-left_testing&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;shift left&lt;/a&gt;, the idea is that the earlier you find an issue with your code, the easier it is to fix it. For one, as you wrote the code recently it&amp;rsquo;s easier to get back into it. And of course, any code issue that doesn&amp;rsquo;t hit production is another potential issue for your end-users prevented.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Running self-hosted GitHub Actions runners in your Kubernetes cluster</title>
      <link>https://sanderknape.com/2020/03/self-hosted-github-actions-runner-kubernetes/</link>
      <pubDate>Mon, 16 Mar 2020 09:23:33 +0200</pubDate>
      <guid>https://sanderknape.com/2020/03/self-hosted-github-actions-runner-kubernetes/</guid>
      <description>&lt;p&gt;Last year November GitHub released &lt;a href=&#34;https://github.com/features/actions&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;GitHub Actions&lt;/a&gt;, a CI/CD solution build on top of GitHub&amp;rsquo;s Source Code Management. GitHub Actions is very convenient to use when your source code is already stored in GitHub as no additional tool is required for your CI/CD requirements. This blog is for example updated through a &lt;a href=&#34;https://github.com/SanderKnape/blog/blob/master/.github/workflows/publish.yml&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;GitHub Actions workflow&lt;/a&gt; whenever I push an update to my GitHub repository (like I just did with this post).&lt;/p&gt;&#xA;&lt;p&gt;Earlier this year GitHub released support for &lt;a href=&#34;https://help.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;self-hosted runners&lt;/a&gt;. These runners run in your own infrastructure which has several advantages. Especially useful is the fact that these runners can access any private resources in your infrastructure such as staging environments for automated testing or secret/artifact management solutions not exposed publicly.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Installing private Git repositories through npm install in Docker</title>
      <link>https://sanderknape.com/2019/06/installing-private-git-repositories-npm-install-docker/</link>
      <pubDate>Mon, 17 Jun 2019 13:30:02 +0200</pubDate>
      <guid>https://sanderknape.com/2019/06/installing-private-git-repositories-npm-install-docker/</guid>
      <description>&lt;p&gt;How do you properly use an SSH key in a Dockerfile? There are many ways to do it, including many ways to do it wrong. What you will want to prevent is that your ssh key ends up in one of your intermediate images or layers. These are the layers that Docker creates with pretty much every command in your Dockerfile. You may think that you properly clean up your secrets later in the Dockerfile, but the secret will then still be available in one of these layers.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Automated deployments to Kubernetes with GitLab</title>
      <link>https://sanderknape.com/2019/02/automated-deployments-kubernetes-gitlab/</link>
      <pubDate>Thu, 28 Feb 2019 13:47:02 +0200</pubDate>
      <guid>https://sanderknape.com/2019/02/automated-deployments-kubernetes-gitlab/</guid>
      <description>&lt;p&gt;In this blog post we&amp;rsquo;ll go through the steps of creating an automated deployment pipeline for Kubernetes using GitLab. In the end we&amp;rsquo;ll have a simple Go application running that very excitingly returns &amp;ldquo;Hello, World!&amp;rdquo;.&lt;/p&gt;&#xA;&lt;h1 id=&#34;prerequisites&#34; class=&#34;relative group&#34;&gt;Prerequisites &lt;span class=&#34;absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100&#34;&gt;&lt;a class=&#34;group-hover:text-primary-300 dark:group-hover:text-neutral-700&#34; style=&#34;text-decoration-line: none !important;&#34; href=&#34;#prerequisites&#34; aria-label=&#34;Anchor&#34;&gt;#&lt;/a&gt;&lt;/span&gt;&lt;/h1&gt;&lt;p&gt;Before we can begin our quest for automation, we&amp;rsquo;ll need to set up some tools. Many alternatives of course exist to the tools that I pick. Feel free to use any other option, but make sure to make any necessary changes if you are following along with this post.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Use Infrastructure as Code for automated security in the deployment pipeline</title>
      <link>https://sanderknape.com/2017/05/infrastructure-as-code-automated-security-deployment-pipeline/</link>
      <pubDate>Mon, 01 May 2017 19:25:02 +0200</pubDate>
      <guid>https://sanderknape.com/2017/05/infrastructure-as-code-automated-security-deployment-pipeline/</guid>
      <description>&lt;p&gt;Infrastructure as Code (IaC) is a very powerful concept. The idea is that you put all infrastructure resources - networks, subnets, load balancers, firewalls and so on - in code. You then deploy your infrastructure the same way application developers deploy their code: through a continuous integration / continuous deployment (CI/CD) pipeline. Other benefits already reaped by application developers that become available are code linting, automated testing and an audit trail of your changes if combined with a version control system. The most well known IaC tools are &lt;a href=&#34;https://www.terraform.io/&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;Terraform&lt;/a&gt; (supports many different services) and &lt;a href=&#34;https://aws.amazon.com/cloudformation&#34; target=&#34;_blank&#34; rel=&#34;noreferrer&#34;&gt;CloudFormation&lt;/a&gt; (specifically for the AWS cloud).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Integration tests with Travis CI</title>
      <link>https://sanderknape.com/2016/09/integration-tests-travis-ci/</link>
      <pubDate>Tue, 20 Sep 2016 19:46:02 +0200</pubDate>
      <guid>https://sanderknape.com/2016/09/integration-tests-travis-ci/</guid>
      <description>&lt;p&gt;Do you write integration tests? What about unit tests? I believe that more people say &amp;ldquo;Yes&amp;rdquo; to the second question than to the first. Which is kinda weird - for many applications, it really isn&amp;rsquo;t that hard to write integration tests. It might not even be necessary to setup your own infrastructure to run these tests. Many CI tools these days allow you to install databases, queues and such on their build agents. With your external dependencies available on your build server, a complementary sets of tests can be run next to your unit tests.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
