Embed Size (px)
Citation preview
GitHub Enterpriseで実現するDevOpsGitHub Actionsを使ったCI/CDの構築2019/10/24Yuichi TanakaSolutions Engineer, GitHub
すべての会社が ソフトウェアの会社に62％のCEOがビジネスをデジタル化する予定だと回答
競争に打ち勝つための社内カルチャーの変化を
● イノベーションの中心となるWalmart labsを開設
● 組織間の壁をなくすために組織改編を行い
コラボレーションを促進するカルチャーを確立
● Facebook や Googleと、タレントの争奪戦
● 一ヶ月に14,000回のソフトウェアデリバリー
Background photo here. Crop if necessary.
https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
GitHub Enterpriseで実現するDevOps GitHub
ソフトウェアデリバリのパフォーマンスは 組織全体の業績に重要な影響を及ぼす
• デプロイの頻度
• リードタイム（コミットからデプロイまでの時間）
• 障害からの復旧時間• 障害発生頻度
上位グループと下位グループの比較
208倍 頻繁なデプロイ
106倍 高速なリードタイム
1/7倍 少ない変更失敗率
2,604倍 迅速な障害復旧
Continuous Integration 継続的インテグレーション
Continuous Delivery 継続的デリバリ
CI/CDプロセスの確立オープンソースの活用 セキュリティ
ソフトウェア企業としての成功に必要な要素
GitHub Enterprise
CI/CDプロセスの構築
CI(継続的インテグレーション)
ソースコードの変更 ビルド・テストの実行
CD(継続的デリバリー)
ソースコードの変更 ビルド・テストの実行 デプロイステージング環境テスト環境運用環境
各フェーズにおけるバグの修正コスト
$0
$4,000
$8,000
$12,000
$16,000
要件 設計 開発 テスト 運用
HTTPS://AGILEELEMENTS.WORDPRESS.COM/2008/04/22/COST-OF-SOFTWARE-DEFECTS/
運用時 VS 開発時
テスト時 VS 開発時
14倍
7倍
GitHub Flow
Create a Feature Branch
なぜブランチを作るのか？• 他の開発者の邪魔をしない
• フィーチャーブランチ上であれば、ビルドが壊れても誰にも影響を与えない
• 頻繁にコミットしても問題ない環境を作る
• 他の開発者からのレビューやCIによるビルド結果を早い段階で得ることができる
Add commits
Open a Pull Request
Discuss and Review Code
Pull Request• 関係者を巻き込んで議論
• チームメンバーによるコードレビュー
• プロダクトオーナーの意図通りの変更になっているか議論
• QA担当者とテストの内容について議論
• セキュリティ担当者と脆弱性の有無について議論
• 法務担当者と使用しているライブラリのライセンスについて議論
継続的インテグレーション
コミットのたびにビルドを実行し結果をフィードバックGitHub Actions
Actionsからのフィードバック• コミット毎のCIの実行結果を✔ or ✗で表示
• 実行ログを確認可能
• 失敗にすぐに気づくことができる
Deploy
Merge
GitHub ActionsによるCI/CD
GitHub内に組み込み
20ジョブまで並行実行が可能
コミュニティの力を利用したワークフロー
いかなるプラットフォーム、言語、クラウドに対しても利用可能
Demo
Linux, macOS, Windowsに加えコンテナの実行も可能
マトリックスビルド
実行中閲覧可能、検索、各行がリンク化されたログ
組み込みのシークレット情報管理
簡単に作成、共有が可能
社内やオープンソースコミュニティが作成したCI/CDプロセス中の処理をコンポーネント化し、再利用する事が可能
GitHub Marketplace上で公開中
- JIRAのチケットを作成
- Azureにデプロイ
- Slackに通知
- JavaScriptのテストを実行
- …
コミュニティのベストプラクティスの活用
アクションはJavaScript Actions、Docker
Actionsの２種類で記述可能
独自のアクションを作成する上で多数の
オープンソースライブラリを利用可能
どちらの方法でもすべてのGitHub APIや
他のパブリックAPIを利用する事が可能
独自のアクションも作成可能
GitHub社内での利用事例 - JavaScriptライブラリのリリース自動化 - https://github.com/github/learning-lab-components
https://github.com/github/learning-lab-components/packages/11396
処理の流れトリガー：Pull Requestをmasterへマージ
1. ドラフトのリリースノートにマージしたPull Requestの内容を記載
2. ライブラリのバージョンが上がっていたらリリースノートを公開
3. バージョン番号がルールに従っているかどうかをチェック
4. GitHub Package Registryにパッケージを登録
https://github.com/JamesMGreene/node-draft-releaser
https://github.com/JasonEtco/validate-semver-release
処理の流れトリガー：Pull Requestをmasterへマージ
1. ドラフトのリリースノートにマージしたPull Requestの内容を記載
2. ライブラリのバージョンが上がっていたらリリースノートを公開
3. バージョン番号がルールに従っているかどうかをチェック
4. GitHub Package Registryにパッケージを登録https://github.com/github/learning-lab-components/blob/master/.github/workflows/release_management.yml
40
GitHub Enterprise: クラウド・サーバ・ハイブリッド
GitHub Connect
• ユーザー管理をシンプルに
• クラウド・サーバを横断検索
• コントリビューショングラフ統合
Enterprise Server
• 御社のDCまたはプライベートクラウドへインストール
• SAML, LDAP, および CASとの連携
• 24/7 の緊急サポート
• 1万ユーザー以上でも容易にスケール
Enterprise Cloud• SaaS版 GitHub.com
• SAML との連携
• 24/5 のサポート・8時間のレスポンスタイム
• 99.95% 稼働率のSLA
• Enterprise Cloud + Enterprise Serverの両方が利用可能
• $252/ユーザー/年 (サポート込み)
• 毎月50,000分までActionsによるジョブの実行が無料
GitHub Enterprise
追加利用分
Linux $0.008/分
Windows $0.016/分
macOS $0.08/分
今後の予定
2019/11/13にGA予定
Self hosted runnerご自身のハードウェア/VM上での実行
近々提供開始予定
CI/CD Test Night #5GitHubにおけるGitHub Actions利用法
• ビルドキャッシュの導入
• UIの改善
• シンタックスの改善
• ブラウザ上でYAMLファイルを編集する際のオートコンプリート、エラー表示
• ドキュメントの改善
その他鋭意開発中
CI/CDプロセスの確立オープンソースの活用 セキュリティ
ソフトウェア企業としての成功に必要な要素
GitHub Enterprise
