I couldn’t wrap my head around CI/CD, untill Github Actions came around

Before you read: You may come across certain booboo’s in this post, if you have any valuable insights, find a spelling/grammatical error feel free to let me know @DeBelserArne 💙

A little introduction

I have never ever created a web application which needed to be up and running 100% of the time, so I didn’t really need CI/CD to make sure everything is running smooth.

I feel that nowadays I am increasingly looking for adventure, not the special kind of adventure that comic book heroes participate in. But more of the kind where I’m looking for things to challenge myself. I measure my success with the amount of challenges I complete.

And that’s going to be what this article is about, one of my challenges: CI/CD…

I have to admit, this is by far one of the most challenging quests that I have ever brought upon myself. 

Things I tried in the past

  1. Gitlab CI/CD

The first service I came in touch with was Gitlab’s built-in CI/CD pipelines, they’re free to a certain extend, work nicely together with your version control, only one small problem. I couldn’t figure out how to set it up.

I would scoure the internet for other people’s gitlab-ci.yml configs to get some more insights, but most of it was pretty overwhelming.
But the result was always the same, one time I would be missing some kind of php extension which would throw a FATAL ERROR the other time some kind of linux package would not be able to install properly.

In the end my feed would be full of failures.

  1. Circle CI

The second service I came across was Circle CI. I liked their documentation a lot. It’s well written and divided into clear parts. But it wouldn’t take long before my CircleCI feed would look like this:

Was I doing something wrong?

In the beginning I had the feeling that everyone else had some knowledge which I hadn’t. I wasn’t sure my workflow was proper, I was mostly running trial & error based without any plan whatsoever.

If you’re interested in my workflow, here’s a list of the steps I took:

  1. I would make some changes to the .yml file.
  2. Then I would push the changes to the repo.
  3. Setting up the environment usually took somewhere between 2-4 minutes 💤.
  4. The process would fail, I would google for an answer.
  5. Redo this process over and over again while you squash bugs 🔙 .

I’m pretty certain this is not the most optimal way to go about this, so if you have any valuable insights, please let me know! @DeBelserArne 💙

Eureka moment when I discovered Github Actions ✅

A few days ago I saw some advertisement regarding Github Actions, I was not sure what it was, but I soon found out I could use it for CI/CD.

Since then I’ve written a fully functional .yml which builds the enviroment nicely and is able to run all my tests. Note: You can find my .yml files at the end of this article.

The really cool thing is that from now on, whenever dependabot makes a pull request to bump a dependency to a new version, a test is run to see if the new version passes all my tests. I know that for many of you this is probably daily fare, but for me this was a unique event.

I’m both thrilled and curious what the future will hold, I know for a fact that around the end of November the Github Actions BETA will end and that it will become a paid service. But I read somewhere that the first 2000 minutes a month remain free.

❗ DISCLAIMER:
Github Actions is not only about CI, it has other benefits, but I haven’t really explored them yet.

Thanks for reading through the article, in the end I guess it became more of a revelation then a real article. But I had fun writing it, and if you had fun reading it, we’re both in a good spot, Cheers! 👍

If you ever had a simular challenge, or have had some headaches trying setup other stuff, feel free to hit me up on twitter! @DeBelserArne 💙

Extra: for those interested I want to share my two .yml files

				
					name: Push

on:
push:
branches:
- development

jobs:
laravel-tests:
runs-on: ubuntu-16.04
steps:
- uses: actions/checkout@v1
- name: Copy .env
  run: php -r "file_exists('.env') || copy('.env.example', '.env');"
- name: PHP information
  run: php -v
# - name: Install ext-intl
#   run: |
#     sudo apt-get autoremove --purge php7.3-fpm
#     sudo apt-get install php7.3-intl
- name: Install Dependencies
  run: composer install --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist
- name: Generate key
  run: php artisan key:generate
- name: Create Database
  run: |
    mkdir -p database
    touch database/database.sqlite
- name: Execute tests (Unit and Feature tests) via PHPUnit
  env:
    DB_CONNECTION: sqlite
    DB_DATABASE: database/database.sqlite
  run: vendor/bin/phpunit
				
			
				
					name: Pull

on:
pull_request:
branches:
- development

jobs:
laravel-tests:
runs-on: ubuntu-16.04
steps:
- uses: actions/checkout@v1
- name: Copy .env
  run: php -r "file_exists('.env') || copy('.env.example', '.env');"
- name: PHP information
  run: php -v
# - name: Install ext-intl
#   run: |
#     sudo apt-get autoremove --purge php7.3-fpm
#     sudo apt-get install php7.3-intl
- name: Install Dependencies
  run: composer install --no-ansi --no-interaction --no-scripts --no-suggest --no-progress --prefer-dist
- name: Generate key
  run: php artisan key:generate
- name: Create Database
  run: |
    mkdir -p database
    touch database/database.sqlite
- name: Execute tests (Unit and Feature tests) via PHPUnit
  env:
    DB_CONNECTION: sqlite
    DB_DATABASE: database/database.sqlite
  run: vendor/bin/phpunit
				
			
Share on facebook
Share on twitter
Share on linkedin
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x