Workflowができたこれまでは「deployment」とか「test」とか、CircleCIが準備している箱に設定を書いていきましたが、これからは「Job」という概念を自分で定義し、「Workflow」という概念で管理していく形になります。実行順序も自由に決められるようになったし、並列処理もできるようになりました。jobが一つだけであればworkflowを定義しなくても大丈夫です。実行方法は?configファイルを2.0系用にアップデート&置き場所を変更して、いつも通りプッシュするだけでOK!configファイルはプロジェクトルートから.circle.ymlだったのを.circleci/config.ymlに変更します。2.0はローカル環境で実行できるよトランスレーターをあてにすると死ぬ「でもconfigを書き換えてくれるAPIがあるんでしょ、知ってるよ」と油断している方。私もそう考えていました。config-translationがあれば楽勝だと...!でもそれは簡単な設定しかしていない一部のユーザーだけかと思います。私の場合、1つ目のステップからコケまくる使えないconfigが出てきて、結局ゼロから作りました。こちらは構造を勉強するくらいにとどめておき、あてにしないほうが賢明かと思います。概要ここからは実際にどのような変更したかの説明です。前提情報として、私が対応したプロジェクトだとこんな構成でした。やっているタスクは、テストの実行とデプロイのみstaging環境とproduction環境の2つを持っており、developブランチがプッシュされた場合はstaging環境に、masterブランチがプッシュされた場合はproduction環境にデプロイする。<productionデプロイのためのコマンド>pythonのバージョン指定はデプロイに必要だったので。上記に貼り付けた2.0の設定ファイルを、各ブロックごとに解説していきます。masterなんとなく読めばわかって頂けるかと思いますが、build-test-deployという名前のworkflowを作成します。build、test、deployという3種類のジョブを走らせていて、testはbuildが正常終了したら実行deoployはtestが正常終了し、かつブランチ名が「develop」または「master」のときのみ実行という感じです。build次に各ジョブを見ていきます。buildジョブから。~/caches/images.tarmachineキーは実行タイプのを指定しています。macOS(macOSのVM)の3種類から選ぶ事ができます。公式サイトによるとdockerがベストプラクティスらしいですが、docker-composeでvolumeを使用する場合は実行タイプをmachineにしなければならないらしいので、そうしています。しないとハマる次のrestore_cache→run→save_cacheではdockerイメージを作成してそれをキャッシュに保存しています。することで、2回目移行、時間のかかるイメージの作成をスキップし、次のtestジョブにすぐ移れるようになります。Dependenciestest次にtestジョブです。test_resultsbuildジョブでキャッシュしたimageファイルをロードし、テストの実行をしていきます。その際、テストのログを出力するようにした方がいいでしょう。CircleCI上から見れるようになります。1.0系では$CIRCLE_TEST_REPORTS/hoge.xmlというところに吐いていましたが、2.0系では出力先をstore_test_resultsキーで指定する必要があります。fi私のプロジェクトではデプロイにpythonが必要だったので、dockerイメージをcircleci/python:2.7.13に指定しています。いうのがある方は参考にしてください。最後のDeployステップで、ブランチがmasterのときとそれ以外のときでコマンドを変更するようにしています。upLoginユーザーは見つかりませんでした。