Ver. 2.1
さて、ここまでCircleCIの設定方法の基本について若干駆け足で紹介しました。
実は、CircleCIの設定はバージョンを指定することができ、ここまで紹介した設定方法はすべて2.0です（.circleci/config.ymlの先頭にversion: 2.0と書いたことを思い出してください）。
ここからはまだ公開されたばかりの2.1を解説していきたいと思います。（2018/10月執筆時）
Ver. 2.0の問題点
Ver. 2.0で設定の柔軟性が格段に向上しましたが、問題点もありました。2.0ではユーザーがCI/CDのほぼすべての設定を書くので、.circleci/config.ymlが肥大化しがちです。筆者は2000行（！）を超える.circleci/config.ymlを見たこともあります。また、CircleCIとYAML両方の制限により設定の再利用性があまりありません。
Ver. 2.1には2.0をベースとし、これらの問題を解決するためのいくつかの構文が追加されました。
2.1の仕組み：Build Processing
2.1ではBuild Processingという仕組みが導入されました。これは、内部的なアーキテクチャのアップデートで、これにより.circleci/config.ymlでシンタックスシュガーが使えるようになりました。2.1で導入された新しい構文は基本シンタックスシュガーなので、ビルドの実行時にすべて2.0の設定に展開されます。2.1のビルドのページのConfigurationというタブを見るとそれが分かります。
それでは、2.1で新た追加された設定を見ていきましょう。
Commands
commandsは複数のステップを1つにまとめて再利用する方法です。
version: 2.1
commands:
run-rails-test:
description: "Railsのテストを実行"
steps:
- run:
command: |
bundle exec rake db:create
bundle exec rake db:schema:load
- run: bundle exec rspec
上記の例ではテストDBの作成とテスト実行を1つにまとめたrun-rails-testというCommandsを定義しています。定義したコマンドは通常のステップのように使うことができます。
steps: - run-rails-test
今回の設定ではCommandsを使うメリットは分かりずらいかもしれませんが、次回に説明するワークフローを使い始めると、異なるジョブでなんども同じコマンドを実行する必要がある場合Commandsが役にたちます。
Parameters
Commandsにはパラメータを渡すこともできます。parametersを使います。
commands:
say-greeting:
description: "パラメータの例"
parameters:
greeting:
type: string
default: "Hi!"
steps:
- run: echo << parameters.greeting >>
これも実践的な例ではないのですが、挨拶をするだけのCommandsを定義して、挨拶の言葉をパラメータで渡しています。parametersキー配下に実際のパラメータを定義します。ここではgreetingというパラメータを定義しています。typeは渡すパラメータの型で、おなじみの文字列型（string）と真偽型（boolean）や別のステップを渡すためのステップ型（step）、また選択肢を指定できる列挙型（enum）が現在サポートされています。defaultは何も渡さなかった時のデフォルトです。
steps:
- say-greeting:
greeting: "Good morning!"
When: ステップの条件実行
whenはステップを条件付きで実行したい時に使います。以下はもっとも簡単な例です。
steps:
- when:
condition: true
steps:
- run: echo "hello!"
条件分岐の判定を直接書いても意味がないので今度はparameterを使って分岐するようにします。
myjob:
...
parameters:
preinstall-foo:
type: boolean
default: false
steps:
- when:
condition: << parameters.preinstall-foo >>
steps:
- run: echo "hello!"
...
workflows:
workflow:
jobs:
- myjob:
preinstall-foo: false
- myjob:
preinstall-foo: true
myjobを定義してワークフローで同じジョブを2度実行しています。1回目はpreinstall-fooがfalseなのでecho "hello!"は実行されませんが、2回目はtrueなので実行されます。
なお、見慣れないworkflowsという設定がありますが、ジョブやワークフローについては次回で詳しく説明します。
Executors
executorsはジョブを実行する環境を簡潔に書くことができます。
executors:
my-executor:
docker:
- image: circleci/ruby:2.5.1-node-browsers
jobs:
job-one:
executor: my-executor
steps:
...
job-two:
executor: my-executor
steps:
...
2.1以前では上記のようにjob-oneとjob-twoを定義する場合、dockerの定義をそれぞれのジョブに書かないといけませんでしたが、2.1ではmy-executorでまとめることができます。
Pre/Postステップ
似たようなジョブを複数定義する場合、ほとんど同じだけど少しだけ違う挙動をさせたい時があります。このような場合、pre/postステップで簡単に微調整できます。
workflows:
build:
jobs:
- job-one:
pre-steps:
- run:
command: echo "this is pre!"
- job-two:
post-steps:
- run:
command: echo "this is post!"
まとめ
CircleCIを設定していくイメージを掴んでもらえたでしょうか？ 前回の記事でも書きましたが、CI/CDはプロジェクトの初期段階で導入するのがおすすめです。今回紹介した機能を使えばCircleCIを使って基本的なCI/CDを始めることができるので、この記事を参考にして導入してみてはどうでしょうか？
次回はもっと高度なCI/CDを可能にするワークフローを解説するのでご期待ください。
