Hnoss

Hnoss

GitLabのドキュメントが、CC BY-SA 4.0.になったー!やったー!
カレンダー

文書タグ

フノス(訳者)(215) IT(191) 解説記事(147) マニュアル(82) GitLab CI(60) オープンソース(50) GitLab(40) Linux(38) メディア(34) コンテナ(29) ウェブ制作(27) DTM(19) HTML5(19) Libre Music(18) おすすめ オープンソース・ソフトウェア(18) プラグイン(14) 百科事典(14) 文化(12) ソフトウェア(11) セキュリティ(11) 録音(11) ミキシング(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) シーケンス(8) 芸能(8) 業務効率化(8) 音楽編集(8) コマンド(8) 音楽(7) 経済(7) ハンドブック(7) マスタリング(7) Raspberry Pi(6) アプリ(6) Google(5) ワークフロー(5) WordPress(5) JACK(5) マイクロサービス(5) 北米(4) Windows(4) Android(4) 映像制作(4) GNU(4) 法律(4) 欧州(4) 音楽プレーヤー(4) Ubuntu(4) Python(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Java(3) ソーシャルメディア(3) DAW(3) スマホ(2) 牛(2) 歴史(2) ニュース(2) GNOME3(2) iOS(2) PlayStation(2) 仮想通貨(2) 古代エジプト(2) マーケティング(2) 有角神(2) エジプト(2) ALSA(2) OS X(2) ERPシステム(2) 電子ブック(2) トヨタ(2) バト(2) Krita(2) 電子書籍(2) ウィッカ(2) GPL(2) ERP(2) オカルト(2) Twitter(2) ロスレス音源(2) BountySource(2) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 日記(1) 聖書(1) 任天堂 DS(1) 教育(1) bi-modal IT(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) Papagayo(1) 写真(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) ヤーウェ(1) CD(1) タブレット(1) 学校(1) 日本(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) アップストリーム・パッケージング(1) 画像(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) サウンドフォント(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) ポータブルソフトウェア(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) クヌム(1) 魔女裁判(1) オンデマンド(1) リーナス・トーバルズ(1) バフォメット(1) UNIX(1) 黙示録(1) スタジオジブリ(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) 政治(1) イボ人(1) 国際(1) クリエイティブ・コモンズ(1) amazon(1) キリスト教(1) レビ記(1) Synfig(1) 独占(1) アマナイ(1) 広告(1) KXStudio(1) EU(1) イケンガ(1) 国際公文書館会議(1) マイナビ(1) 募金(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) 出エジプト記(1) 観光案内(1) 絵文字(1) サンフランシスコ(1) パキスタン(1) リクルート(1) ハトホル(1) パン(1) 地方(1) Blender(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ツイッター(1) Youtube(1) 中南米(1) モヘンジョ=ダロ(1) CC(1) 声明(1) 悪魔(1) ラジオ(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) ゲーム(1) パシュパティ(1) 1Password(1) アピス(1) 宗教(1) テレビ(1) OpenToonz(1) 電子教材(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) デザイン(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional

site_image
Getting started with GitLab CI/CD
https://docs.gitlab.com/ee/ci/quick_start/README.html
Hnoss Hnoss     最終更新:2018-03-23 21:54:11    PDF


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設定が掲載されています。ぜひ、参考にしてください。

原文: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 Plugin system
GitLab Documentation > Administrator documentation >GitLab Plugin system GitLab 10.6より導入。  カスタムプラグインを使えば、GitLa...
UX Department
現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが...
Team Handbook
現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに...
Engineering
現在の位置: チームハンドブック 目次 >エンジニアリング   連絡方法 Public Issue Tracker (GitLab CEの場合) ; 不特定多数に公開して...

新着文書

Bristol’s Last Bookshop shares key facts on the remains of publishing
ブリストルの ラスト・ブックショップ (「最後の書店」)はたぶん、真の本好きのための残本店と言っていいだろう。それは、いくつかの出版社の名作...
Second social leader opposed to dam construction murdered in one week
一人の社会指導者は昨日プエルトリコ・バルディビアで虐殺された。これはアンティオキアで一週間以内に連続して起きた二回目の類似の殺人である。5月8...
Avianca strike leaders fired / Justice for Colombia
コロンビア第一の航空会社アビアンカは昨年9月20日から11月9日の長期にわたり行われたストに参加したパイロット14人を解雇した。解雇された一人、ハイ...

新着Wikipedia翻訳

Flutter (software)
Flutter -------- 原作者:Google 開発者:Googleとコミュニティ 最初の公開:アルファ(v0.0.6)/2017年5月;1年前(2017-05)[1] 試験版の公...
E (programming language)
E(プログラミング言語) AmigaE や e(検証言語) 、 GNU E と混同しないこと。 E -------- パラダイム マルチパラダイム:オブジ...
Van Eck phreaking
Van Eck phreaking(ファン・エック・フリーク) Van Eck phreakingは盗聴の一形態であり、その中では特殊な装置が使用され、電子機器を探るため、隠...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-03-23 21:54:10 Hnoss
2 2018-02-24 15:10:36 Hnoss
3 2018-02-24 14:18:29 Hnoss
4 2018-02-20 23:48:18 Hnoss
5 2018-02-18 22:59:04 Hnoss
6 2018-02-18 22:58:48 Hnoss
7 2018-02-18 22:58:11 Hnoss
8 2018-02-18 22:57:34 Hnoss
9 2018-02-18 22:52:25 Hnoss
10 2018-02-18 22:52:24 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →