GitHub Actionsセミナーメモ

# GitHub Enterprise で実現するDevOps

https://www.microsoftevents.com/profile/form/index.cfm?PKformID=0x7718523abcd

2019/9/11＠MS本社

## GitHub Actionsを使ったCI/CDの構築

Speaker : Yuichi Tanaka (Solution Engineer, GitHub)

* あらゆる企業がソフトウェア企業になるべき：現在のトレンド
* Walmart：競争に打ち勝つための社内カルチャーの変化を
    * Walmart Labs　イノベーションの中心となる組織として開設
    * 一か月に14,000回のソフトウェアデリバリー
    * ECサイト好調→18年度の売上好調、株価も上昇
* ソフトウェアの本業でない会社がどのように技術力を高めるか？
* State of DevOps レポート
    * ソフトウェアデリバリのパフォーマンスは組織全体の業績に重要な影響を及ぼす
        * デプロイ頻度
        * リードタイム（コミットからデプロイまでの時間）
        * 障害からの復旧時間
        * 障害発生頻度
    * ソフトウェアデリバリのパフォーマンスの上位グループと下位グループで大きな乖離が発生
        * 208倍頻繁なデプロイ
        * 106倍高速なリードタイム
        * 2604倍迅速な障害復旧
            * 下位グループは障害発生に気づいてすらいない場合も
        * 1/7倍少ない変更失敗率
            * このギャップを埋めるのが、CI/CDである
                * CI/CDのプロセスをいかに確立するか
    * オープンソースの活用が強大な生産性、利益の差を生み出す
    * ※上位グループが利用するOSS:1.75倍
        * より速い進化スピード
        * OSCのベストプラクティス活用
        * 車輪の再発明の防止
            * オープンソースを使うにあたってのチャレンジ：セキュリティやコンプライアンスに対する新たな懸念が発生
* GitHub Enterprise
    * ソフトウェア企業に必要な要素
        * OSSの活用
        * CI/CDプロセスの確立
        * セキュリティ
    * CI/CDプロセスの構築
        * 各フェーズにおけるバグの修正コスト 
            * 7倍：テスト時VS開発時
            * 14倍：運用時VS開発時
                * (https://agileelements.wordpress.com/2008/04/22/COST-OF-SOFTWARE-DEFECTS/)
        * GitHub Flow
            * なぜブランチを作るのか
                * 他の開発者の邪魔をしない
                    * フィーチャーブランチ上であればビルドが壊れても誰にも影響を与えない
                    * ＝頻繁にコミットしても問題ない環境を作る
                * 他の開発者からのレビューやCIによるビルド結果を速い段階で得ることができる
            * Pull Request
                * 関係者を巻き込んで議論
                    * チームメンバーによるコードレビュー
                    * プロダクトオーナーの意図通りの変更になっているか議論
                    * QA担当者とテスト内容について議論
            * コミットのたびにビルドを実行し結果をフィードバック
                * GitHub Actionsからのフィードバック
                    * コミットごとのCIの実行結果
                    * 実行ログを確認可能
                    * 失敗にすぐに気づくことができる
        * GitHub ActionsによるCI/CD
            * GitHub内に組み込み
            * 20ジョブまで並行実行が可能
            * コミュニティの力を利用したワークフロー
            * いかなるプラットフォーム、言語、クラウドに対しても利用可能
        * GitHub Actionsの設定：YAMLファイル一つで設定する
            * GitHub上のVM/コンテナ上でビルドを実行：ビルド用VMとか用意不要
        * GitHub Actionsの特徴
            * Linux,mac,Windowsに加えコンテナの実行も可能
            * マトリックスビルド
                * OS等、様々な環境の組み合わせでのビルド実行可能
            * 実行中閲覧可能、検索、各行がリンク化されたログ
            * 組み込みのシークレット情報管理
        * コミュニティのベストプラクティス活用
            * 社内やOSCが作成したCI/CDプロセス中の処理をコンポーネント化し、再利用可能
            * よく実行する処理は社内で共有したり、OSCで作成されたコンポーネント（Action）を利用できる
                * GitHub Marketplace上で公開
        * いかなるワークフローも自動化
            * ソースコードのコミットだけでなく、Jiraのチケット作成等のアクションもトリガーとして実行可能
        * オープンソースを安全に活用：解決すべき問題
            * 社内にセキュリティエンジニアがいない、少ない
            * 直接利用しているOSSの脆弱性だけでなく、そのOSSが利用している別のOSSの脆弱性の影響も考慮する必要がある
                * GitHub上でセキュリティ脆弱性アラート機能あり
                    * プロジェクト内で使っているライブラリをサーチし、脆弱性があればアラートしてくれる
                    * GitHubが保有する脆弱性データベース
                        * CVE
                        * GitHub上のパブリックリポジトリに対して機械学習と人手によるレビューを組み合わせて脆弱性を検出
                        * WhiteSource社の脆弱性データベース
                            * ＝脆弱性データベースの拡充への投資も大きく行っている
            * 70%：一か月経過してもパッチ適用されていない脆弱性
                * 自動セキュリティフィックス
                    * 脆弱性を解消するバージョンまでライブラリのバージョンを上げたプルリクエストを自動的に作成する
    * GitHub Enterprise
        * Enterprise Cloud
            * GitHub Connect
        * Enterprise Server：オンプレ版
        * クラウド版、オンプレ版の両方が利用可能
            * $252/ユーザ/年（サポート込み）
            * 毎月50,000分までのActions実行込み

## Q&A
* Selfhosted Runners
    * 自身のハードウェア、VM上でのジョブ実行を可能とする
        * 無料で利用可能
        * 特別なライブラリ・コンポーネント等が必要なビルドを行う場合に有用
    * 今年後半から利用可能に？
* ActionsはAzure Pipelineをforkして作成しているので似ている
    * Actionsはコミュニティ、エコシステムの力で様々な拡張が可能なのが強みと考えている