Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

More than 5 years have passed since last update.

GitLab CI

Last updated at Posted at 2017-12-10
1 / 66

自己紹介

  • 名前: 政倉 智
  • 所属: codeArts 株式会社/html5j 鹿児島/GitLab.JP
  • 趣味: プログラミング/バイク

こんなこともやってます

  • GitLab の毎月リリースの紹介を一年前からやってます
  • GitLab CE へのバグ報告を気が向いたらやってます
  • GitLab Runner のバグ修正をたまにやってます

Agenda

  • GitLab CI って?
  • Hello, world!
  • より便利に使ってみる
  • おまけ

GitLab CI って?


  • 継続的インテグレーション (Continuous Integration) 機能
  • ソースコードのビルドなどを GitLab サーバー側で動作できる
  • メリットはおいておいて、とりあえず使ってみましょう!

Hello, world!


とりあえす Hello, world! をしましょう!


GitLab でプロジェクトを作ります

image.png


README ファイルを作成する

image.png


image.png


Set up CI で設定する

image.png


image.png


.gitlab-ci.yml
build:
  script:
    - echo 'Hello, world!' > hello.txt
  artifacts:
    paths:
      - hello.txt

パイプラインが開始されます

image.png


実行ログを見よう!

image.png

image.png


image.png


成果物のダウンロード

image.png


成果物のプレビュー

image.png

image.png


解説

.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

こんな感じに

image.png


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}

こんな感じ

image.png

image.png


ステージ

.gitlab-ci.yml
stages: # build ステージが終わってから deploy ステージを実行
  - build
  - deploy

# ...

build:branches: # HTML/PDF 変換は build ステージ
  stage: build

# ...

deploy:master: # build ステージが終わってから実行される
  stage: deploy

# ...

  • ジョブを直列で動かす時はステージを使う
  • ステージのジョブがすべて終わったら、次のステージのジョブが開始される
  • ステージ内のジョブは並列で動作する
  • ステージ内のジョブの成果物は後続のジョブへコピーされる

image.png


成果物

.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 からアクセス

image.png


いったんまとめ

  • ブランチの Environment のリンクは Merge Request にもリンクが表示される
  • Merge Request でコードと成果物の両方のレビューが即座にできる
    • 手元でビルドしたり、ジョブを探さなくていい

おまけ


ロールバック

  • 公開したドキュメントに重大な問題が!
  • しかも修正に時間がかかるぞ!
  • そんな時は慌てずロールバック!

image.png


HTML 以外でも使う

  • GitLab Environment は URL があれば何でも OK!
    • URL さえ分かれば、さくらのクラウドでも OK!
    • Kubernetes に Docker Container を起動させてってのをよくやるらしい
    • パイプラインの実行前に URL が確定できるのが条件
  • exe/ipa/apk でも同じことができそう (試してないけど!)

プロジェクトメンバーのみに公開したい!

みんなでイイネつけよう!


まとめ


  • GitLab CI は、手軽に成果物の作成ができる
  • GitLab Environment は、成果物や URL がついたものなら何で扱える
  • GitLab Environment は、環境ごとの最新のリリースへ手軽にアクセスできる
  • ReviewApps は、GitLab Environment へ簡単にアクセスできる

GitLab を使うと...

  • 手軽に好きな成果物にアクセスできる
  • ソースコードとアプリの両方のレビューが手軽になる
  • ステージングデプロイができる
  • 手動でジョブを起動し、本番系へデプロイができる
  • ロールバックも手軽になる

GitLab を使って楽をしましょう!

0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?