この記事の目的
この記事は、
「GitHub x CircleCI x Azure でやってみようDevOps！」セミナーの受講メモ
を目的としています。
CircleCIについては、アカウント登録して、ちょっと触ったことがある程度なので、
ほぼ知識はない状態での参加となっています！
要約(イベント概要)
CircleCI Japan と Microsoft Japan の第1回共同セミナーです！
「GitHub x CircleCI x Azure でやってみようDevOps！」と題し、3社のエンジニアから直接、ソフトウェアの開発からデプロイまでを効率的に実現するTipsをお伝えします。
本題
★凡例
[>]が付いているのは、発表中にアナウンスがあった内容のメモです。
ついていないのは、自分の心の中で思ったメモです。
★CI/CD導入の背景
＞新しい作業に費やす時間をおおくとる企業がより成果を出している傾向にある。
単純作業、繰り返しする作業などを自動化するということは、
確かに自分の周りでもよく言われています。
単純作業をなくして、クリエイティブな作業に時間を割くためにも、
CI、CDや、RPAといった技術の導入が必要なのはよくわかります。
★CI/CDについて
CIについて
＞CIの対象スコープは開発チーム。
＞すべてのコミット/プッシュに対してテスト（CI)をする。
CIの関係者が誰であるか、考えたことがなかったので参考になりました。
確かに、どういうテストをするとか、静的コード解析をするかということは、
開発者チーム内で閉じたスコープで検討できますね！
また、CIでは、主にビルド、テスト、静的コード解析が主なターゲットとなります。
CDについて
＞CDの対象スコープは開発チーム、インフラチーム、プロダクト責任者、品質管理者etc.など、範囲が広い場合がある。
CIと同じように、CDにも、誰がどう関与するかを考える必要があるという気付きを得られました。
Sierとして考えると、デプロイは、アプリケーションの出荷という側面があるので、
出荷判定を含めて社内でもいろいろな役割の人の合意が必要ですし、
お客様にも受け入れ確認をしていただく必要があるという点で、
いろいろと考えなくてはいけないなということに気が付けました・・・
（誰だよCI/CD環境くらいサクッとできるっていったやつ・・・）
＞CDには、2種類の定義がある。
＞継続的デリバリー・・・（本番環境に）デプロイ可能な状態まで自動化。アプリケーションのデプロイ実行は人間の判断が介入する。
＞継続的デプロイメント・・・（本番環境に）デプロイするところまで含めて自動化。
一言で「CDやろう」といったとき、どっちのことを考えているかについて、
チーム内で意識合わせをしておく必要がありそうです。
これからCD環境の構築もやっていくことになるので、
上記の２つの違いについて認識を合わせていこうと思います。
CI/CDのtips
＞CI/CDを導入する場合、Step by Stepで着実に自動化することが大事。
WEBアプリケーションのマイクロサービス化でも言われているようなことですが、
何を解決したいかを明確にして、それに焦点を当てる形で
スモールスタートすることは、どの分野でも大事なんだなと、改めて感じました。
なお、CircleCIでは、より良いCI/CDをするための指標のプラクティスを公開しているそうです。（以下のリンクからたどれます）
今は英語しかないけど、いずれ日本語化対応をする予定とのことでした。
https://www2.circleci.com/rs/485-ZMH-626/images/5-Key-Metrics-Engineering.pdf
Commit-to-Deploy Time (CDT)
・・・コードをコミットしてからデプロイされるまでの時間について
Build Time
・・・ビルドにかかる時間
Queue Time
・・・CI待ち（テストとかが始まるまで）の時間
How Often Master Is Red
・・・マスターブランチがバグってる時間
Engineering Overhead
・・・ツールの修正とかの時間
What Else?
・・・そのほかに気を付けたほうがよいであろうことリスト
★CircleCIの特徴
Config.ymlでテスト環境を設定
ワークフロー
＞ビルド設定を分割ｓて並列処理を行うための処理ができる。
＞決まった時間に定期実行することもできる。
＞タグ指定で、タグ毎のワークフローを設定することができる。
ビルドの高速化(リソースの再利用)
ビルドの高速化(並列処理)
＞10個のテストを４つの処理で実行することができる
設定のパッケージングと再利用(Orbs)
＞Config.ymlの肥大化に対応するもの。
＞一度作ったConfig.ymlをOrbs Registryを公開することができる。
＞今はPrivate Orbsがない。
＞一番使われているOrbsは、GitからCloneするときの時間を短縮するために作られたもの。
DokcerHubのようなイメージと認識しました。
Config.yml作ったことがないので、まだ理解できてないですが、
先人たちの知恵を借りれる公式のレジストリがあるのはとても便利そうです。
★その他気づき
レビューのタイミングについて
＞CIを導入することで変わることにレビューのタイミングがある。
＞ウォーターフォールでは・・・レビューの後、テスト。
＞CI導入後・・・テスト（静的コード解析含む）の後、レビュー。
確かに、些末なレビュー指摘をすることがなくなったり、
ビジネスロジックの内容にだけ集中することができたりと、メリットが大きい・・・
GUIベースのテストのサポート
質疑の中で、ブラウザテストのサポートについてちょっと触れていたので、調べてみました。CircleCIでは、以下のページのように、ブラウザテストをサポートしています。
https://circleci.com/docs/2.0/browser-testing/#selenium
正直に、Dockerで自動UIテストができることを認識していなかったのでびっくりしました。
seleniumをインストールして、実行することでUIテストも自動化できるようです。
また、テスト実行時のログ、キャプチャーも取得できるようなので、
手作業テストからのExcelエビデンス張りという魔のテスト作業から脱却できそうですｗ
DockerでSelenium環境を作れる点も大きいですねｗ
これで、テストが増えたとき、コンテナを増やすことでサクッと対応できそうです。
これについては、別途調査していこうと思います！
どうでもいいこと
CircleCIって早口で言うと、サンクチュアリに聞こえる～
感想
Circle CIの概要とか主な特徴を知ることができました。
知ることはできましたが、GitLabやAzure DevOpsのPiplineなど、
競合ツールと同使い分けるかというところまでは、考えが至りませんでした。
そろそろ仕事の方でも、CI/CDツールの選定作業が始まるので、
そういう観点でも調査を始めようと思った今日この頃でした。
