SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

エンジニアのためのCI/CD再入門

モダンなCI/CDでは欠かせないワークフローを使った高度なビルド管理

エンジニアのためのCI/CD再入門 第3回


  • このエントリーをはてなブックマークに追加

 前回はCircleCIを実際に使ってCI/CDの設定方法を学びました。今回は一歩進んでワークフローを使った高度なCI/CDについて学びたいと思います。ワークフローを使うと複雑なビルドの設定を分割したり、並列性を高めて全体のビルドスピードを上げたりすることができます。ワークフローはモダンなCI/CDでは欠かせない機能なので今回でしっかりマスターしましょう!

  • このエントリーをはてなブックマークに追加

 これからCI/CDを導入する方にも、すでに活用されている方にも、CircleCIを通してCI/CDに対する理解を深めるお手伝いができれば幸いです。

対象読者

  • 前回の記事を読んでCI/CDに興味を持たれた方
  • CI/CDについて学びたい方
  • CircleCIのワークフローを使ってみたい方
  • 新機能Orbsについて詳しく知りたい方

必要な環境/知識

  • GitHubのアカウント
  • ソフトウェアのテストについての一般的知識
  • アジャイル開発についての一般知識

筆者について

 CircleCIの元開発者で、現在はCircleCI初の海外支社であるCircleCI Japanでさまざまな活動を行っています。

CI/CDパイプライン

 CircleCIでワークフローと呼ばれる機能は、実は似たような名前で他のCI/CDサービスやツールにも用意されています。例えばCircleCIと同じくSaaS版CI/CDの代表であるTravis CIには"Build Stages"がありますし、Jenkinsには"Pipeline"という機能が存在します。

 どれも呼び方は違いますが、これらはすべてCI/CDパイプラインを実現するための機能です。CI/CDパイプラインとはCI/CDで行われる処理を論理的にまとめて、それらを順番に実行していくことを意味します。

 この説明だけだとよく分からないですね。具体的に例を出して説明すると、あるアプリケーションのCI/CDを回そうとしたときはだいたい以下のような処理が必要となります。

  • 依存関係のインストール
  • 静的コード解析
  • テストの実行
  • デプロイメント

 これらの各処理を個別に定義して、パイプラインとして実行します。パイプラインとは日本語で管の意味で、CI/CDの処理が管の中を通って順番に実行されるのでそう呼ばれています。

 パイプラインを使う一番のメリットはCI/CDの処理を分割できることです。そうすれば各処理を並列に実行したり、「if 処理1 then 処理2」のようなフローを作ったりすることができます。例えば、先ほどの例だと静的コード解析とテストの実行は並列で実行できそうです。また、デプロイメントをテストが成功した時だけ実行するように設定すれば安全にリリースの自動化を行うことができます。

 このように、パイプラインは複雑な手順を抽象化して扱う手助けをしてくれるので、モダンなCI/CDには必須の機能となっています。また最近ではCI/CDベンダーではないGitHubもGitHub Actionsと呼ばれるパイプライン機能を発表したことで、パイプラインの重要性はCI/CDの世界を超えて認識されつつあります。

ワークフローの設定

 それでは実際にCircleCI上でワークフローを設定していきましょう。サンプルコードは前回と同じRuby On Railsで書かれたブログアプリを使います。

 前回の内容を簡単におさらいすると、このブログアプリのCI/CDを回すためにbuildというジョブを定義して、その中で依存関係のインストールやテストの実行ができるように設定しました。

 依存関係のインストール、静的コード解析、テストの実行をそれぞれのジョブに切り出すところから始めましょう。最終的な設定を全部書くと紙面を取るので、ここでは完成形の.circleci/config.ymlへのリンクだけを掲載しておきます。

 ジョブの定義方法については前回解説したので、ここではワークフローに関する部分だけを見ていきましょう。

version: 2
jobs:
  install_dependency:
    <省略>
  run_test:
    <省略>
  run_lint:
    <省略>

 まず、それぞれのジョブをjobs配下に定義します。

workflows:
  version: 2
  test-and-lint:
    jobs:
      - install_dependency
      - run_test:
          requires:
            - install_dependency
      - run_lint:
          requires:
            - install_dependency

 そして、それらのジョブをworflowsでまとめます。

  • workflows:ワークフローの定義を開始します。
  • version: 2:ワークフローのバージョンを指定します。2018年12月の時点では2のみ指定可能です。
  • test-and-lint:このワークフローの名前を指定します。分かりやすい名前であればなんでも構いません。
  • jobs:実行するジョブを指定します。
  • requires:このジョブを実行する前に実行されるべきジョブを指定します。この例では、run_testrun_lintのジョブは必ずinstall_dependencyのあとに実行されます。複数のジョブをrequiresすることも可能です。

 この.circleci/config.ymlをGitHubへプッシュするとCircleCIでtest-and-lintという名前のワークフローが開始されます。

workflow
workflow

 このようにワークフローを使うと設定を分割できるだけではなく、CI/CDの全体の流れが可視化できるようになり、とても便利です。

requiresの補足説明

 requiresを使わずにジョブを書くと各ジョブが順番に実行されるように思うかもしれませんが、実際にはすべてのジョブが並列で実行されます。ジョブを順番に実行したい場合は、下記のようにrequiresを使う必要があります。

jobs:
  - job1
  - job2:
      requires:
        - job1
  - job3:
      requires:
        - job2

 なお、無料枠でCircleCIを使用している場合、並列ビルドができないのでrun_testrun_lintは1つずつしか実行されません。

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
失敗したワークフローの再実行

修正履歴

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
エンジニアのためのCI/CD再入門連載記事一覧

もっと読む

この記事の著者

金 洋国(CircleCI Japan)(キム ヒロクニ)

CircleCIで2.0などのプロダクト開発に携わった後、CircleCI Japanを立ち上げてからはTech Leadとして技術全般を担当。趣味は電動キックボードで日本で普及するように様々な活動をしています。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11306 2019/01/16 10:41

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング