GitHub x CircleCI x Azure でやってみようDevOps!に参加しました

概要

GitHub x CircleCI x Azure でやってみようDevOps!に参加した内容をまとめました。

microsoft-events.connpass.com

CircleCI セッション

  • CircleCIは日本語サポートを今後完全に行う予定
    • 日本のページから行けば日本語で問い合わせを対応

DevOpsの歴史と重要性

  • 2010年

    • 継続的デリバリー
      • ソフトウェアが常にデプロイ可能な状態に保つというプラクティス
  • Puppet社が調査

    • 業績が高い会社ほどテストパターンとデプロイパターンの再利用をしている
    • 優れた企業は、
      • 予定外の作業や同じ作業に費やす時間が21%少ない
      • 新しい作業に費やす時間が44%多い

CI/CDとはなんなのか

CI継続的インテグレーション

  • what
    • 共有リポジトリの全てのコミットをトリガーにしてビルドとテストを繰り返すこと
  • why
    • チームの生産性、効率、満足度をあげること
  • できること
  • CIは比較的開発チームに閉じているもの
  • 解決する問題
    • 全てのコミットに対してCIすると
    • 早い段階でバグを発見できる
    • 設定で制御可能
    • 静的解析などで標準化
    • コードの品質UP
    • テスト失敗したコードのマージブロック
    • masterブランチの安全保障

CD継続的デリバリー/デプロイメント

  • CDには2種類存在する

    • 常にリリース可能な状態を維持する
    • 自動でステージング・本番環境へデプロイする
  • Continuous Delivery(継続的デリバリー)

    • リリース作業に人間の意思が介在する
  • Continuous Deployment(継続的デプロイメント)

    • リリース作業に人間の意思が介在しない
  • 大事なのはCDを考える時にステップを刻むこと、ステークホルダーを巻き込むこと

    • 一足跳びに本番自動デプロイは難しい

5 Metrics You Should

Know to Understand Your Engineering Efficiency

https://www2.circleci.com/rs/485-ZMH-626/images/5-Key-Metrics-Engineering.pdf

  • commit-to-deploy time
    • コードがコミットされてからデプロイされるまでの時間
  • Build Time
    • CIビルドにかかる時間
  • Queue Time
    • CIビルドが始まるまでに待たされる時間
  • How often Master is Red
    • masterブランチが壊れている時間
  • Engineering Overhead
    • ツールのメンテナンスなど開発時間にかかっている時間

これらの指標を理解しておいて最適化する

CircleCIのご紹介

Dockerをサポート

  • 高速にビルド環境を立ち上げることができる

.circleci/config,ymlでテスト環境を統一することができる

  • コンフィグはファイルに書かれるべき
    • コードと同じくレビューとバージョン管理を行う
  • 明示的であるべき
  • その結果のデメリット
    • 一から設定を書かないと行けない
    • 冗長になりがち
      • これらの点を解決しているのが後述するorbs

ワークフロー

  • ビルド設定を分解して、依存関係や並列処理を行う
  • ワークフローのタイプ
    • スケジューリング
    • マニュアル承認
    • ブランチ指定: 特定のブランチへのコミットによって実行
    • タグ指定: Gitのタグによって実行

SSHデバッグ

  • Rebuild wth SSHでコンテナが起動したまま維持してくれるので今ビルドされているdockerコンテナに入れる
    • 入ってエラーログなどを確認できる

ビルドの高速化

キャッシュ

  • 同一ジョブ間のキャッシュ
    • 外部のライブラリなどを毎回ダウンロードするのには時間がかかるのでキャッシュしておく
  • 同一ワークフロー内のキャッシュ
    • 一番最初のジョブで実行コードを作る
    • そのあといろんなテストで使い回す

並列処理

  • テストを並列にdockerコンテナを起動して行う
    • 4並列で合計400個のテストを実行など
  • どのテストファイルを分けるか?
    • 前回のテスト結果からどう分けると一番早いのか自動で判断してくれる
      • 便利!
  • 設定のパッケージングと再利用(Orbs)
    • 設定のメンテナンスが難しくなる問題への対応策
    • 設定を再利用することができる
    • 他の人が書いたCircleCIの設定を自分のプロジェクトのconfigに差し込める
      • プライベートorbsがないので公開には注意が必要(公開したら全公開しかない)
      • orbsには公式、公認パートナー、3rd partyの3つ種類がある
      • 一番使われている3rd partyは日本人が作ったもの

GitHub x CircleCI x Azure

デモ

  • CIが入るとレビューのタイミングが変わる

    • テストが終わった状態でレビューができる
  • Azureとの連携

    • クラスターを作ったり消したりするのに時間がかかる

質問

  • Windowsのサポートはあるか?
    • 興味がある人にだけclosedなバージョンを提供している
    • 使ってみたいという相談があれば提供

GitHub セッション

エンタープライズオープンソースの両方の世界のデファクトスタンダード

DevOps?

今や当たり前のプラクティス 今はDevSceOpsが重要 Securityの観点を入れる そして自動化する

Security?

  • 99%のプロジェクトがオープンソースを利用している
  • 広く使用されているオープンソースソフトウェアにバッグドアが仕込まれる
    • 去年npmのライブラリに悪意あるコードが埋め込まれた
      • メンテナーに新しく参加した人によるもの

開発者に役立つ機能

  • セキュリティ脆弱性アラート
    • 去年2千7百万件のアラートを送っている
    • WhiteSourceという脆弱性業界の会社と連携している
    • 先に踏み込んだ機能
      • ディペンデンシー・インサイト
        • アラートの上がっているライブラリを利用しているリポジトリの可視化、どれくらいの危険度なのか可視化
  • 脆弱性の修正をオープンソース上で行うと脆弱性があることが周囲にバレてしまい悪用される可能性が生まれる

  • 70%以上の脆弱性がアラートの後パッチ適用されていない

  • 解決するツールDependabot

    • 解決するパッチを自動で当てるツール
    • 解決するp-rを出せる(出してくれる)
  • Open source開発の持続可能なものにしていきたい

    • Sponsor機能
      • 善意とボランティアで動いていたものを持続可能なものにするもの
  • GitHub Sponsors Matching Fund
    • 寄付額と同じ額をGitHubも払う(寄付額の倍の金額をコントリビューターヘ送られる)
    • GitHubは手数料を取っていないので全額送られる

Microsoft セッション

Azure Container Registryを使い倒す

ACR=docker hubのimageの置き場所 docker imageのプライベートレジストリ

ACRタスク

  • Azureのクラウド上docker buildできる
  • 使っているbaseのイメージがアップデートされたらbuildし直す

geo-replication

  • コンテナイメージを構築するためのコードをコミットすると別のリージョンにもプッシュされる

    • premiumプランのみサポート
  • circleCIにACRの拡張がある

Microsoft Learn

感想

  • 存在するとは聞いたことがあったけど、並列でのテスト実行で前回のテスト結果からどう分けると一番早いのか自動で判断してくれるの便利
  • 開発者やステークホルダーの満足度をあげるためもCI/CDは必要
    • 特にアジャイル開発だと常に最新で動かせる成果物があることが重要なので必須と言っても良さそう
    • 例えばスクラムのスプリントレビューで毎回成果物の確認のために工数がかかっていてはまずい(そのうちやらなくなることもありえる)
  • GitHubは最近新しい機能が増えてるなとは思っていたけどちゃんと使ってなかったので今回知ったのを機に使っていきたい
  • Microsoft LearnのACRのラーニングやってみる!