「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

acai

English⇒Japanese

jhoo0509

English⇒Japanese

yoko

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

【GitLab 公式 を訳してみた】GitLab CI/CD の使い方

GitLab Documentation>GitLab Continuous Integration (GitLab CI)>GitLab CI/CD の使い方 

 注:GitLab バージョン 8.0から、GitLab 継続的インテグレーション(CI)機能が登場しました。GitLab では全てのプロジェクトにデフォルトで使用可能なように設定されています。

  GitLab は、継続的インテグレーションサービスを提供しています。レポジトリの rootディレクトリに.gitlab-ci.yml」というファイルを追加すれば、あとはGitLabプロジェクトをランナーが読み取り、コミットあるいはプッシュ、CIパイプラインのトリガーなど各作業を実施してくれます。

  GitLabランナーにどのような作業をさせるかについては、「.gitlab-ci.yml」ファイルで指定します。ランナーは、パイプラインを動作させて、アプリケーションを組み立てることが仕事です。デフォルトの状態では、パイプラインを3つのステージbuild , test , deploy)に分けて操作します。かといって、これら全てのステージに合わせてビルド工程(job)を考えなくてはならないわけではありません。そのステージにjobがなかった場合は、そのステージを無視して次の工程に移ります。

  jobが成功した(戻り値が0ではなかった)場合、コミットに関連して緑色のチェックマークが付きます。「自動的に実施されたテストが失敗したようなので、コミットに影響が出ている」というような情報を、あえてコードを開いて確認する前に、ざっと理解することができます。

  GitLab CIサービスを使ってテストスーツを実施すると、どこかが駄目だったときなどに、GitLabのユーザーインターフェイスからすぐさまフィードバックを得られます。

  継続的デリバリー並びに、継続的デプロイなどの、コードのテストからデプロイまでを段取りよく機械に自動化させる手法が、開発環境の一部になりつつあります。

  そんなに難しいことではありません。CIを動かすのに必要な操作は、基本的にこの2つだけです。

  1. レポジトリのrootディレクトリに「.gitlab-ci.yml」ファイルを置く
  2. Runnerを設定する

 たったこれだけで、Gitレポジトリにプッシュされるたびに、ランナーがパイプラインを開始します。パイプラインの結果がプロジェクトのPipelinesページに表示されるはずですので、ぜひご確認ください。
 

  このページでは次のことを前提に説明していきます。

  • GitLabインスタンスは、バージョンが 8.0以上になっているか、GitLab.comを使用していること。
  • GitLab内にプロジェクトがある状態で、CIの使用を否定してないこと。

 以上のことがわかれば、あまり深く考えずとも、GitLab CIを使うことができるようになるはずです。次はもう少しだけ細かい使い方を紹介します。
 
 

  .gitlab-ci.yml」ファイルを作成する

  「.gitlab-ci.yml」ファイルを作成するまえに、まずは簡単な解説を入れさせていただきます。
 

  .gitlab-ci.yml とは

  「.gitlab-ci.yml」とは、CIが皆さんの開発プロジェクトに対して、どのようなことを実行するかを定義する命令書です。レポジトリのrootディレクトリに設置することで機能します。

  レポジトリにプッシュがあったときには、GitLabがこの「.gitlab-ci.yml」ファイルを探し出します。そして、ランナーにこのファイルの内容に従ってjobを実行するように命じます。コミットが実施されるのは、それらのjobが終了してからです。

  レポジトリに配置した「.gitlab-ci.yml」とバージョン管理は、古いバージョンのビルドを難なくこなし、フォークも円滑に進めることができます。ブランチにはそれぞれ異なるパイプラインとjobを設けることができ、CIの信頼できるソースとして機能します。
 「.gitlab-ci.yml」が、なぜこのような機能になったかについては、こちらのブログポストをご覧ください。

 

  簡単な「.gitlab-ci.yml」ファイルを作成してみよう

 注:.gitlab-ci.yml」は、YAMLファイルです。書式はYAML記法に則ることから、スペースと思われるところは、タブで空白を設けることになっています。

  このファイルの名前は、必ず「.gitlab-ci.yml」としたうえで、レポジトリのrootディレクトリに配置してください。「CIに通すのは、YAMLファイルであれば何でもよい」というわけではありません。

 コツは、最初は基本的なスクリプトを書くにとどめて、後から不足している部分を埋めていくように、だんだんと内容を充実させていくことです。
 たとえば、「Ruby on Rails」プロジェクトの初歩的な設定例は、このようになります。

============================================
before_script:
 - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs
 - ruby -v
 - which ruby
 - gem install bundler --no-ri --no-rdoc
 - bundle install --jobs $(nproc)  "${FLAGS[@]}"

rspec:
 script:
  - bundle exec rspec

rubocop:
 script:
  - bundle exec rubocop
============================================

 「これが決して外せない要素だ」ということさえ確定すれば、後からそこにアプリケーションを追加していくような感覚で設定を充実させていくことができるでしょう。

 この例示は、次の点を考慮していただくと、より正しく解釈していただけるはずです。

  1. rspec」と「rubocop」というjobは、それぞれ異なるコマンドを実行させるために設けたものである。(このjob名は筆者の独断で命名した) 
  2. どのjobも、「before_script」に記されたコマンドの影響を受ける。


 「.gitlab-ci.yml」ファイルには、「どのような」jobを「いつ」実行するかを定義します。
 jobはスクリプトやキーワードをまとめ上げたものなので、job名(『rspec』『rubocop』など)を使って、定義したスクリプト群を指し示すことができます。
 逆に言えば、jobを作り上げたのなら、そこに何らかのスクリプトやキーワードを入れなくてはなりません。
 ランナーは自身が構築した環境の中で、いくつものスクリプトをjob単位で切り分けて処理していきます。
 

  ここで大切なのは、それぞれのjobで実行されるスクリプトは、他のjobと同じものであってはならないことです。
 

  「.gitlab-ci.yml」の内容が正しいかどうかを判定するツールがありますので、一応きちんと通しておきましょう。
 GitLab インスタンスの「/ci/lint」という部分、
つまり、「 CI/CD ➔ Pipelines and Pipelines ➔ Jobs」と移動した先の「CI Lint」ボタンにツールが埋め込まれています。

  「.gitlab-ci.yml 」で扱える全機能については、こちらの説明書に掲載されています。

 

  「.gitlab-ci.yml」ファイルをGitLabにプッシュする

  「.gitlab-ci.yml」を作成して、レポジトリのrootディレクトリにファイルを置いたら、今度はそのレポジトリをGitLabにプッシュしましょう。

======================
git add .gitlab-ci.yml
git commit -m "Add .gitlab-ci.yml"
git push origin master
======================

  「Pipelines」ページに移動すると、パイプラインの処理状況をご確認いただけます。

  「Commits」ページに移動すると、コミットSHAが終了するまで、一時停止アイコンが表示されています。
  (写真1)新しいコミットがあると表示される画面。よく見ると黄色い一時停止アイコンが表示されている。

  それをクリックすると、このコミットの内容が示されたjobsページに移動します。
 (写真2)jobsページ

   jobsページには、たくさんのjobが未処理のまま並べられています。
 実は、ランナーの設定がきちんと終わっていない限り、「.gitlab-ci.yml」で定義したjobは実行されません。

  よって次の章では、ランナーが正確に働くようにするための設定方法をざっと確認します。
 

  Runnerを設定する

  Runner(ランナー)は、「.gitlab-ci.yml」で定義したjobを実行する機関です。ランナーは仮想マシン、VPS、Bare Metal Machine、Dockerコンテナ、またはコンテナクラスターで運用できます。GitLabとランナーはAPIを通じて相互にやり取りをすることから、ランナーが入っているマシンはインターネットアクセスが可能な状態にしなくてはなりません。

  ランナーには、特定のプロジェクトのために構築された物と、GitLabで複数のプロジェクトを処理するものがあります。全てのプロジェクトを処理するランナーのことを、共有ランナーをいいます。

  (各ランナーの違いについては、Runners説明書に解説されています。)

  GitLabサーバーで扱えるランナーそれぞれの設定、仕様などは、プロジェクトの「Settings ➔ CI/CD」で確認してください。ランナーのセットアップの方法は単純明快です。
 GitLab公式から配信されているランナーについては、Go言語でプログラムされており、https://docs.gitlab.com/runner/から説明書をご覧いただけます。
 

  しかし、どのランナーについても、

ことの2点については変わりありません。

  上のリンクに載っている方法がうまくいったら、それぞれのランナーを「プロジェクト専用」にするか「共有」にするかを選択しなくてはなりません。

  これらの設定内容は、プロジェクトのランナー画面(Settings ➔ CI/CD)に表示されます。
 (写真3)「プロジェクト専用」にするか「共有」にするか

 

  共有ランナー

  GitLab.comをお使いの方なら、GitLab Inc提供の共有ランナーをご利用いただけます。

  GitLabが用意した環境で動作する、特殊仮想マシンです。どんなプロジェクトでもビルドできます。

  皆さんのプロジェクトの「Settings ➔ CI/CD」から、「Enable shared runners」をクリックすると、プロジェクトで共有ランナーを扱えるようになります。

  詳しくは、Shared Runnersをご覧ください。

 

  パイプラインとjobの状況を確認する

  ランナーの設定がうまくいったら、コミットした変更が果たして上手くいっているのか、失敗しているのかなどを確認しておいた方が良いでしょう。

  全てのパイプラインが現在どのような状況にあるかは、プロジェクトの「Pipelines」ページで確認します。
 (写真4)コミットの状態

  それぞれのjobの状態を確認したいのなら、「Pipelines ➔ Jobs」に移動してください。
 (写真5)コミットの状態(2)

  さらに、jobの状態が書いてある部分をクリックすると、そのjobのログを確認することができます。jobの失敗や動作異常が起こったときには、このダイアログを見ることで解決の糸口を探れることがままあります。ここ重要です。
 (写真6)Jobのログ

  皆さんが管理しているプロジェクトの他にも、GitLab内のコミットマージリクエストなど、様々なページのjob記録を閲覧することができます。

 

  具体例

  『GitLab CI 設定サンプル集 』というページには、それぞれのプログラミング言語に応じたCI設定が掲載されています。ぜひ、参考にしてください。

PDF
更新日:2018-03-23 21:54:11 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://docs.gitlab.com/ee/ci/quick_start/README.html 原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

[翻訳]GitLabハンドブック>エンジニアリング

現在の位置: チームハンドブック 目次 >エンジニアリング   連絡方法 Public Issue Tracker (GitLab CEの場合) ; 不特定多数に公開しては問題が発生するような一部の題材に…2018-05-26 00:10:26

[翻訳]GitLabハンドブック>UX部門

現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが社におけるデザインの原論、表現法、…2018-05-26 00:09:10

【GitLab 公式 を訳してみた】GitLab UX ガイド

GitLab Documentation > GitLab development guides >GitLab UX ガイド  現在、UX documentationの内容を、 design.gitlab.com projectに移行しております。この説明書の更新…2018-05-26 00:06:03

[翻訳]GitLabハンドブック>インフラストラクチャ>Gitaly チーム

現在の位置: チームハンドブック 目次 > インフラストラクチャ >Gitaly チーム   関連リンク Gitaly専用 パブリックイシュー トラッカー チャットチャンネル ;チャンネル…2018-05-24 18:53:54