自己紹介
- 名前: 政倉 智
- 所属: codeArts 株式会社/html5j 鹿児島/GitLab.JP
- 趣味: プログラミング/バイク
こんなこともやってます
- GitLab の毎月リリースの紹介を一年前からやってます
- GitLab CE へのバグ報告を気が向いたらやってます
- GitLab Runner のバグ修正をたまにやってます
Agenda
- GitLab CI って?
- Hello, world!
- より便利に使ってみる
- おまけ
GitLab CI って?
- 継続的インテグレーション (Continuous Integration) 機能
- ソースコードのビルドなどを GitLab サーバー側で動作できる
- メリットはおいておいて、とりあえず使ってみましょう!
Hello, world!
とりあえす Hello, world!
をしましょう!
GitLab でプロジェクトを作ります
README
ファイルを作成する
Set up CI
で設定する
.gitlab-ci.yml
build:
script:
- echo 'Hello, world!' > hello.txt
artifacts:
paths:
- hello.txt
パイプラインが開始されます
実行ログを見よう!
成果物のダウンロード
成果物のプレビュー
解説
.gitlab-ci.yml
# .gitlab-ci.yml ファイルに実行する処理や設定を書く
build: # ジョブ名
script: # 実行するコマンドを並べる
- echo 'Hello, world!' > hello.txt
# `hello.txt` を成果物にする
artifacts:
paths:
- hello.txt
もう少し .gitlab-ci.yml について
複数のジョブ
.gitlab-ci.yml
# ジョブをたくさん並べると並列で実行できます
job1:
script:
- echo job1
job2:
script:
- echo job2
たくさんのコマンドの実行
.gitlab-ci.yml
# コマンドはたくさん書けます
# 順次実行されます
build:
script:
- echo one
- echo two
- echo three
成果物
.gitlab-ci.yml
build:
script:
- echo 'Hello, world!' > README
artifact:
expire_in: '4 weeks' # 四週間で成果物を破棄します
paths:
# 成果物には複数のファイルを含められます
- README
- index.html
- *.png
# ジョブで生成されたファイルを取得したいときは必ず成果物を設定する
# デフォルトでは成果物の寿命は二週間なので注意```
GitLab CI って何がうれしい?
CI のいいところ
- 手動ビルドでのよくある失敗を防げる
- 担当者ごとの環境差が出たり
- 間違えてデバッグビルドしたり
- 誤ったファイルが混入したり
- 忙しかったり
- 誰が問題を起こしたのかがすぐに分かる
- 失敗したら、そのコミットをした人が犯人
- 自動テストまで含めておくとかなり強力
- テスト担当者に成果物を渡しやすい
- すっごい古い成果物でテストしてたり
GitLab CI のいいところ
GitHub + Circle CI などと比べて、統合されている
-
.gitlab-ci.yml
を書くだけ - GUI も統合されている
- 外部サービスにプロジェクトのアクセス権を渡さなくていい
より便利に使ってみる
ユースケース
- AsciiDoc で書かれたドキュメントを HTML/PDF に変換する
- HTML/PDF は GitLab Pages を使って公開する
- ドキュメントの修正は必ずレビューを受ける
AsciiDoc -> HTML/PDF 変換
.gitlab-ci.yml
build:branches:
stage: build
image: asciidoctor/docker-asciidoctor
variables:
REVNUMBER: ${CI_COMMIT_REF_NAME}-${CI_JOB_ID}
before_script:
- export REVDATE="`LANG=C date +'%B %d, %Y'`"
- export SUPPORT_URL="${CI_PROJECT_URL}"
script:
- rake pdf
- rake html
only:
- branches
artifacts:
paths:
- ./*.html
- ./*.pdf
こんな感じに
Docker Image を指定
.gitlab-ci.yaml
build:branches:
# Asciidoctor 公式の Docker Image を使ってビルド
# AsciiDoc 変換 asciidoctor コマンドをインストール済みの仮想マシン
# https://hub.docker.com/r/asciidoctor/docker-asciidoctor/
image: asciidoctor/docker-asciidoctor
バージョンや作成日
.gitlab-ci.yml
build:branches:
variables:
# master-1234 のようにバージョンを環境変数にセット
# バージョンをもとに、いつどのリビジョンで作られたのか判断できる
REVNUMBER: ${CI_COMMIT_REF_NAME}-${CI_JOB_ID}
before_script:
# 作成日を生成
- export REVDATE="`LANG=C date +'%B %d, %Y'`"
HTML/PDF 生成
.gitlab-ci.yml
build:branches:
# Ruby の Rake 使ってます
# 今日は中身気にしないでね!
# 内部で REVNUMBER とか REVDATE 使ってます
script:
- rake pdf
- rake html
成果物
.gitlab-ci.yml
build:branches:
# 生成した HTML/PDF を成果物として取り出せるように
artifacts:
paths:
- ./*.html
- ./*.pdf
デプロイ
.gitlab-ci.yml
deploy:master:
stage: deploy
variables:
GIT_STRATEGY: none
script:
- echo do nothing
artifacts:
name: ${CI_PROJECT_NAME}-${CI_COMMIT_REF_NAME}-${CI_JOB_ID}
paths:
- .
only:
- master
environment:
name: master
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_ID}
こんな感じ
ステージ
.gitlab-ci.yml
stages: # build ステージが終わってから deploy ステージを実行
- build
- deploy
# ...
build:branches: # HTML/PDF 変換は build ステージ
stage: build
# ...
deploy:master: # build ステージが終わってから実行される
stage: deploy
# ...
- ジョブを直列で動かす時はステージを使う
- ステージのジョブがすべて終わったら、次のステージのジョブが開始される
- ステージ内のジョブは並列で動作する
- ステージ内のジョブの成果物は後続のジョブへコピーされる
成果物
.gitlab-ci.yml
build:branches:
artifacts:
# 成果物のファイル名を分かりやすくする
# 標準は artifacts.zip になる
name: ${CI_PROJECT_NAME}-${CI_COMMIT_REF_NAME}-${CI_JOB_ID}
paths:
- .
GitLab Environment
.gitlab-ci.yml
build:branches:
environment:
name: master # 名前を master に
# master のジョブで最新のジョブの成果物へのダイレクトリンク
# いちいち master の最新のジョブを探しに行かなくてもいいので便利
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_ID}
いったんまとめ
- master にコミットされた修正が即座に HTML/PDF 変換されるように
- 誰でも好きな時に、最新のドキュメントを見ることができる
- 古いドキュメントも (二週間以内なら) 見ることができる
- GitLab Environment を使うと、最新の成果物にすぐにアクセスできる
AsciiDoc -> HTML/PDF (リリース用)
.gitlab-ci.yml
# master の時とほぼ一緒
build:release:
stage: build
image: asciidoctor/docker-asciidoctor
variables:
REVNUMBER: ${CI_COMMIT_REF_NAME} before_script:
before_script:
- export REVDATE="`LANG=C date +'%B %d, %Y'`"
- export SUPPORT_URL="${CI_PROJECT_URL}"
script:
- rake pdf
- rake html
artifacts:
paths:
- ./*.html
- ./*.pdf
only:
- tags
ドキュメントバージョン
.gitlab-ci.yml
build:release:
stage: build
image: asciidoctor/docker-asciidoctor
variables:
# バージョン番号を 1.0 のようにして、正式なリリース版か執筆中のものかを区別できるように
REVNUMBER: ${CI_COMMIT_REF_NAME}
# 以下参考
build:branches:
variables:
# master-1234 のようなバージョン番号
REVNUMBER: ${CI_COMMIT_REF_NAME}-${CI_JOB_ID}
リリースタグの時のみ
.gitlab-ci.yml
build:release:
# タグ (リリースタグ) の時だけ実行される
only:
- tags
# 以下参考
build:branches:
# master を含むブランチの時だけ実行される
only:
- branches
デプロイ
.gitlab-ci.yml
# master の時とほぼ同じ
deploy:staging:
stage: deploy
variables:
GIT_STRATEGY: none
script:
- echo do nothing
only:
- tags
artifacts:
name: ${CI_PROJECT_NAME}-${CI_COMMIT_REF_NAME}
expire_in: '47 yrs'
paths:
- .
environment:
name: staging
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_NAME}
成果物
.gitlab-ci.yml
deploy:staging:
artifacts:
# ファイル名を sample-1.0.zip のようにする
# master の時は sample-master-1234.zip と区別がつく
name: ${CI_PROJECT_NAME}-${CI_COMMIT_REF_NAME}
# 成果物を長期間保持するように
# 無限という設定の方法が分からない...
expire_in: '47 yrs'
paths:
- .
GitLab Environment
.gitlab-ci.yml
deploy:staging:
environment:
name: staging # ステージングという名前
# リリース版へのリンクを設定する
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_NAME}
GitLab Pages で公開
.gitlab-ci.yml
pages:
stage: deploy
variables:
GIT_STRATEGY: none
script:
- mkdir public
- mv *.html *.pdf public
artifacts:
paths:
- public
when: manual
only:
- tags
environment:
name: production
url: https://${CI_PROJECT_NAMESPACE}.gitlab.io/${CI_PROJECT_NAME}/
GitLab Pages
.gitlab-ci.yml
# GitLab Pages は
# pages という名前のジョブで
# public というディレクトリに公開物をコピーして
# public を成果物に登録する
# と、それを公開してくれる
pages:
script:
- mkdir public
- mv *.html *.pdf public
artifacts:
paths:
- public
手動で実行する
.gitlab-ci.yml
pages:
# manual を指定すると、自動では開始されません
# 実行ボタンをクリックして初めて開始される
when: manual
# タグ (リリースタグ) の時だけ実行される
only:
- tags
GitLab Environment
.gitlab-ci.yml
pages:
environment:
name: production
# 公開 URL を設定 (GitLab Pages)
url: https://${CI_PROJECT_NAMESPACE}.gitlab.io/${CI_PROJECT_NAME}/
いったんまとめ
- リリースはリリースタグ (1.0 とか) を打つだけであとはよしなに!
- HTML/PDF のバージョンに 1.0 とかがはいる
- いったんステージングにデプロイされる
- ステージングでドキュメントの最終確認を行う
- 問題がなければ pages ジョブを手動で開始させ、公開する
ReviewApps
.gitlab-ci.yml
# master/staging の時とほぼ同じ
deploy:mergerequest:
stage: deploy
variables:
GIT_STRATEGY: none
script:
- echo do nothing
artifacts:
name: ${CI_PROJECT_NAME}-${CI_COMMIT_REF_NAME}-${CI_JOB_ID}
paths:
- .
only:
- branches
except:
- master
environment:
name: reviews/${CI_COMMIT_REF_NAME}
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_NAME}
GitLab Environment
.gitlab-ci.yml
deploy:mergerequest:
environment:
name: reviews/${CI_COMMIT_REF_NAME} # 名前を reviews/hogehoge のように
# ブランチのジョブの最新の成果物へのリンク
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_NAME}
# 以下参考
deploy:master:
environment:
name: master
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_NAME}
deploy:staging:
environment:
name: staging
url: ${CI_PROJECT_URL}/builds/artifacts/${CI_COMMIT_REF_NAME}/file/index.html?job=${CI_JOB_NAME}
pages:
environment:
name: production
url: https://${CI_PROJECT_NAMESPACE}.gitlab.io/${CI_PROJECT_NAME}/
MergeRequest からアクセス
いったんまとめ
- ブランチの Environment のリンクは Merge Request にもリンクが表示される
- Merge Request でコードと成果物の両方のレビューが即座にできる
- 手元でビルドしたり、ジョブを探さなくていい
おまけ
ロールバック
- 公開したドキュメントに重大な問題が!
- しかも修正に時間がかかるぞ!
- そんな時は慌てずロールバック!
HTML 以外でも使う
- GitLab Environment は URL があれば何でも OK!
- URL さえ分かれば、さくらのクラウドでも OK!
- Kubernetes に Docker Container を起動させてってのをよくやるらしい
- パイプラインの実行前に URL が確定できるのが条件
- exe/ipa/apk でも同じことができそう (試してないけど!)
プロジェクトメンバーのみに公開したい!
- 成果物の HTML プレビューは今のところ公開プロジェクトのみ
- 画像・PDF あたりは非公開プロジェクトでのプレビューはできる
- 非公開プロジェクトでの HTML ファイルはダウンロードになる
- 半年以内に非公開プロジェクトでの HTML プレビューができるようになるらしい
- GitLab Pages は公開プロジェクトのみ
みんなでイイネつけよう!
まとめ
- GitLab CI は、手軽に成果物の作成ができる
- GitLab Environment は、成果物や URL がついたものなら何で扱える
- GitLab Environment は、環境ごとの最新のリリースへ手軽にアクセスできる
- ReviewApps は、GitLab Environment へ簡単にアクセスできる
GitLab を使うと...
- 手軽に好きな成果物にアクセスできる
- ソースコードとアプリの両方のレビューが手軽になる
- ステージングデプロイができる
- 手動でジョブを起動し、本番系へデプロイができる
- ロールバックも手軽になる