はじめに
GitLabCI/CDについて触る機会があったので備忘録代わりにまとめていきます。
そもそもCICDって何？
gitlab公式サイトから画像を引用。
CI/CDとはCI(継続的なインテグレーション) CD（継続的デリバリー）の略。
CD（継続的デプロイ）もあります。
この字面から何となく想像がつく通り、
CICDとは何か特定の技術を指している訳ではありません。
技術ではなくソフトウェア開発手法を指してます。
CI(継続的なインテグレーション）ではリポジトリにpushされてきた時に自動でテストを行います。
自動でテストを行ってくれるのでバグの混入に気づきやすくなります。
CD（継続的デリバリー）ではCIでのテストが終了したものをテストサーバーにビルドし、動作確認が行えるというもの。
CDにはほかにもCD（継続的デプロイ）というものがある。
こちらは自動で本番環境へデプロイを行うこと。
CI/CDの何がいいの？
自動でテストやデプロイを行ってくれるので、人的ミスを防げるし、開発の効率も向上する。
仕様の修正が入る度に手動でテストを走らせるのは手間だし、アジャイルだと開発中に仕様が変更になるケースも多いのではないかなと思います。
GitLab CI/CD
GitLabでCI/CDを行う場合は、リポジトリのルートディレクトリ直下に
.gitlab-ci.ymlという名前のファイルを作成するだけ。
.gitlab-ci.ymlというファイル名をGitLabが検知して、GitLab Runnerが走る。
GitLabRunnerは複数の動作方式が用意されていて、今回はdockerを使用。
下のコードは公式サイトから引用したもの。
before_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- ruby --version
このbefore_scriptはジョブを実行する前に処理が走る。
なので各ジョブに共通の依存関係を持たせたいパッケージのインストールを行う際にこちらのbefore_script属性を使用する。
上記のサンプルコードの場合、before_script属性の処理が走った後に、run_testというジョブが実行される。
before_script以外にも複数の予約語が用意されており、GitLab CICDでやれることは多いのかなと思います。