仕事でちょと触れる機会がありましたので、そこで学んだことをまとめて共有していこうかと思います。CircleCIを使っていこうというのを決めました。デプロイできるような環境を作ろうかという経緯でCircleCIを使ったデプロイの自動化をはじめました。そちらを参考にしてデプロイの自動化を進めていきました。CircleCIを設定するというかこちらのドキュメントをしっかり読めば、こっちの記事はあまり読まなくても良いかもしれません。いえ、この後読まれないのも悲しいのでドキュメントをまとめてわかりやすくなるように説明していこうと思います。今回説明するのはconfigのバージョン2.1で2.0とは異なるので注意してください。2.1だとCommandやExecutorなどの定義が使えるようになり処理の共通化がより簡単にできるようになっています。CIで実行する処理を定義していきます。それを順番にして一つのWorkflow(ワークフロー)を定義していきます。Workflow(ワークフロー)というのがパッとわからない人もいるかと思いますが、まぁ訳した作業全体の流れです。CIだとテストコードを実行1.にパスすることを確認してデプロイという流れが一般的ですがこの1と2の流れがWorkflowです。なりますが基本の考え方は変わりません。・フロントのデプロイの4つのJobから構成され、これらをどういう順番で実行するかというのがWorkflowです。これを簡易的なyamlで書くと以下のようなイメージです。※正しい形式ではないので、実際には公式ドキュメントにならって記述してください。Jobを書いておきます。要はそのJobの依存タスクを書いておく必要があります。デプロイされてしまうなんてこともありえます。(並列数にもよりますが)WorkflowはJobの上位の概念として覚えておければ良いかと思います。Jobの中で実際行う処理を記述していきます。Stepsの中では、シェルコマンドが実行できここにひたすら、処理を記述していきます。できたり、リポジトリからのチェックアウトなどを行うコマンドも用意されています。中だけで有効な環境変数を定義したりすることができます。Command(2.1から使用可)Commandは2.1からの昨日ですが、Commandを活用することでStepsを共通化することができます。ここの処理だけCommandとして定義して再利用します。処理を書く必要なく、コマンドを呼び出すだけで事足りるようになり、DRYなconfigができあがります。parametersという形で引数もこのコマンドに渡せるのでパラメータも使うとより再利用可能なコマンドが作り易くなるかと思います。Executors(2.1から使用可)Executorsは環境を再利用するためのものです。dockerのイメージを環境を作ってそれを使い回すことができます。Orbs(2.1から使用可)Orbsというワードは聞きなれないかもしれませんが、要はライブラリです。共通化ができましたが、Orbsは一度使って公開すると他のプロジェクト、もっと言うとCircleCIを使う全プロジェクトで使うことができます。https://circleci.com/orbs/registry/こちらがOrbsのレジストリになるので使えるOrbsを見ておくと良いかと思います。僕が見た限りではSlackのorbsなどがあったので、それを使うと通知とかが手軽に実装できそうだなという感じでした。Nodeなどのorbsなどもあったので、CircleCIに指定のバージョンの言語をインストールするなんていうのも手軽できそうです。概念まとめここまでで説明してきたものをまとめておくとWorkflowJobsStepsCommandsExecutorsOrbsあたりを理解しておけばとりあえずCircleCIを始められそうです。Executorsは実行環境の共通化と言う感じで理解しておくのが良さそうです。多少踏み込んだ内容をまとめておくと以下のようになります。しないといけないという問題を解消することができます。使い回すことができます。Jobを実行するブランチを制御することができます。これで「developにマージされたら、テスト終了後にデプロイを走らせる」といったことが可能になります。正規表現でのホワイトリストの登録もできるのでfeatureブランチにはテストを実行するといった制御も可能です。秘密鍵を登録しておくことでSSHを利用してリモートサーバにログインさせることが可能です。add_ssh_keysでfingerprintを指定して使用する鍵を登録する必要があります。定義済み環境変数はこちらです。現在ビルドしているブランチ名などなどビルドのメタ情報が環境変数として定義されています。Executor内のenvironmentsで環境変数を定義して使うことができます。変数のスコープはそれぞれ定義した場所により、Jobで定義すればそのJob内、Executorで定義すればその実行環境内で有効です。その他、シェルコマンドやステップ内でも環境変数を設定できますがこちらもそれぞれのスコープのみで有効です。CircleCIのCLIをインストールしておくとローカルでconfigファイルの検証ができます。これの検証を通ったらpushするようにするとリポジトリに無駄にプッシュするのを避けることができます。検証のコマンドはこちらです。validateまとめここまでざーっとCircleCIの概念や導入の際に気になる点をまとめてみましたがいかがでしょうか?実作業ではドキュメントを繰り返し参照しながらConfigを作りましたが、日本語のドキュメントが結構丁寧に書かれているので意外とすんなり入り込めると思います。元のconfigが2.0だったのですが、CommandsとExecutorが使えるようになり、かなりの処理を共通化できるので結構快適になりました。おかげで現場のデプロイをサクッと自動化できました。version1この記事が役に立ちましたらシェアをお願いします。2019フリーランスを退職します。