Enviar búsqueda
Cargar
「継続的デリバリー」読書会 第3章 継続的デリバリー
•
2 recomendaciones
•
741 vistas
Norikazu Hiraki
Seguir
Denunciar
Compartir
Denunciar
Compartir
1 de 34
Descargar ahora
Descargar para leer sin conexión
Recomendados
継続的デリバリー読書会 第 7 章 コミットステージ
継続的デリバリー読書会 第 7 章 コミットステージ
Yasutomo Arai
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
Takuma SHIRAISHI
デプロイメントパイプラインって何?
デプロイメントパイプラインって何?
ke-m kamekoopa
継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
Yusuke HIDESHIMA
少し分かった気になるテスト駆動開発
少し分かった気になるテスト駆動開発
lnial
自動テストの誤解とアンチパターン in 楽天 Tech Talk
自動テストの誤解とアンチパターン in 楽天 Tech Talk
kyon mm
テスト勉強会よしおか100311 1
テスト勉強会よしおか100311 1
Hiro Yoshioka
My style agile
My style agile
Kenji Hiranabe
Recomendados
継続的デリバリー読書会 第 7 章 コミットステージ
継続的デリバリー読書会 第 7 章 コミットステージ
Yasutomo Arai
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
Takuma SHIRAISHI
デプロイメントパイプラインって何?
デプロイメントパイプラインって何?
ke-m kamekoopa
継続的デリバリー読書会資料 #1
継続的デリバリー読書会資料 #1
Yusuke HIDESHIMA
少し分かった気になるテスト駆動開発
少し分かった気になるテスト駆動開発
lnial
自動テストの誤解とアンチパターン in 楽天 Tech Talk
自動テストの誤解とアンチパターン in 楽天 Tech Talk
kyon mm
テスト勉強会よしおか100311 1
テスト勉強会よしおか100311 1
Hiro Yoshioka
My style agile
My style agile
Kenji Hiranabe
継続的デリバリーと読み解く Web 開発あるあるとその対策
継続的デリバリーと読み解く Web 開発あるあるとその対策
Tetsuo Yamabe
Jenkinsを使った初めての継続的インテグレーション
Jenkinsを使った初めての継続的インテグレーション
dcubeio
継続的デリバリー第11章.Ppt
継続的デリバリー第11章.Ppt
Yusuke HIDESHIMA
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
Yoichi Tamamaki
継続的デリバリー読書会 14章
継続的デリバリー読書会 14章
Yusuke HIDESHIMA
WebサービスのソフトウェアQAと自動テスト戦略
WebサービスのソフトウェアQAと自動テスト戦略
Masaki Nakagawa
Fitnesse を用いたテストの効率化について
Fitnesse を用いたテストの効率化について
tecopark
ssmjp 20200221 Automation
ssmjp 20200221 Automation
Sekiguchi Toshihiro
Friendlyで始めるwindowsアプリシステムテスト自動化+内部使用技術解説
Friendlyで始めるwindowsアプリシステムテスト自動化+内部使用技術解説
Tatsuya Ishikawa
テスト自動化入門@Graat勉強会
テスト自動化入門@Graat勉強会
Graat(グラーツ)
Bringing Continuous Agile to Japan
Bringing Continuous Agile to Japan
Andy Singleton
jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー
jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー
Junya Suzuki
言語差異によるTDDプロセスへの影響度の解析
言語差異によるTDDプロセスへの影響度の解析
pocketberserker
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
Yoichi Tamamaki
自動テストのすすめ
自動テストのすすめ
Katsunori Kanda
提案:Qaも実装に踏み込んでみよう
提案:Qaも実装に踏み込んでみよう
Kosuke Fujisawa
Klocworkのご紹介
Klocworkのご紹介
Masaru Horioka
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
Akiko Kosaka
バージョン管理の断捨離
バージョン管理の断捨離
Kazushi Kamegawa
Software Test Basic
Software Test Basic
Akinari Tsugo
(PlayScala(0.9.1) until Play(2.0))
(PlayScala(0.9.1) until Play(2.0))
Takuma SHIRAISHI
継続的12章
継続的12章
shinjiyoshida
Más contenido relacionado
La actualidad más candente
継続的デリバリーと読み解く Web 開発あるあるとその対策
継続的デリバリーと読み解く Web 開発あるあるとその対策
Tetsuo Yamabe
Jenkinsを使った初めての継続的インテグレーション
Jenkinsを使った初めての継続的インテグレーション
dcubeio
継続的デリバリー第11章.Ppt
継続的デリバリー第11章.Ppt
Yusuke HIDESHIMA
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
Yoichi Tamamaki
継続的デリバリー読書会 14章
継続的デリバリー読書会 14章
Yusuke HIDESHIMA
WebサービスのソフトウェアQAと自動テスト戦略
WebサービスのソフトウェアQAと自動テスト戦略
Masaki Nakagawa
Fitnesse を用いたテストの効率化について
Fitnesse を用いたテストの効率化について
tecopark
ssmjp 20200221 Automation
ssmjp 20200221 Automation
Sekiguchi Toshihiro
Friendlyで始めるwindowsアプリシステムテスト自動化+内部使用技術解説
Friendlyで始めるwindowsアプリシステムテスト自動化+内部使用技術解説
Tatsuya Ishikawa
テスト自動化入門@Graat勉強会
テスト自動化入門@Graat勉強会
Graat(グラーツ)
Bringing Continuous Agile to Japan
Bringing Continuous Agile to Japan
Andy Singleton
jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー
jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー
Junya Suzuki
言語差異によるTDDプロセスへの影響度の解析
言語差異によるTDDプロセスへの影響度の解析
pocketberserker
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
Yoichi Tamamaki
自動テストのすすめ
自動テストのすすめ
Katsunori Kanda
提案:Qaも実装に踏み込んでみよう
提案:Qaも実装に踏み込んでみよう
Kosuke Fujisawa
Klocworkのご紹介
Klocworkのご紹介
Masaru Horioka
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
Akiko Kosaka
バージョン管理の断捨離
バージョン管理の断捨離
Kazushi Kamegawa
Software Test Basic
Software Test Basic
Akinari Tsugo
La actualidad más candente
(20)
継続的デリバリーと読み解く Web 開発あるあるとその対策
継続的デリバリーと読み解く Web 開発あるあるとその対策
Jenkinsを使った初めての継続的インテグレーション
Jenkinsを使った初めての継続的インテグレーション
継続的デリバリー第11章.Ppt
継続的デリバリー第11章.Ppt
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
ソフトウェア調達におけるアジャイル開発の要点と現状 Slideshare
継続的デリバリー読書会 14章
継続的デリバリー読書会 14章
WebサービスのソフトウェアQAと自動テスト戦略
WebサービスのソフトウェアQAと自動テスト戦略
Fitnesse を用いたテストの効率化について
Fitnesse を用いたテストの効率化について
ssmjp 20200221 Automation
ssmjp 20200221 Automation
Friendlyで始めるwindowsアプリシステムテスト自動化+内部使用技術解説
Friendlyで始めるwindowsアプリシステムテスト自動化+内部使用技術解説
テスト自動化入門@Graat勉強会
テスト自動化入門@Graat勉強会
Bringing Continuous Agile to Japan
Bringing Continuous Agile to Japan
jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー
jenkinsのすゝめ - 継続的インテグレーションと継続的デリバリー
言語差異によるTDDプロセスへの影響度の解析
言語差異によるTDDプロセスへの影響度の解析
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
なぜアジャイルなのですか?改めて考察するウォーターフォールとの違い
自動テストのすすめ
自動テストのすすめ
提案:Qaも実装に踏み込んでみよう
提案:Qaも実装に踏み込んでみよう
Klocworkのご紹介
Klocworkのご紹介
Agile japan2010 rakuten様プレゼン資料
Agile japan2010 rakuten様プレゼン資料
バージョン管理の断捨離
バージョン管理の断捨離
Software Test Basic
Software Test Basic
Destacado
(PlayScala(0.9.1) until Play(2.0))
(PlayScala(0.9.1) until Play(2.0))
Takuma SHIRAISHI
継続的12章
継続的12章
shinjiyoshida
大崎的デリバリー第2章
大崎的デリバリー第2章
Koji Takahara
継続的8章
継続的8章
shinjiyoshida
継続的デリバリーを支える開発環境
継続的デリバリーを支える開発環境
智治 長沢
Netty 入門 - 「Netty ベース」の何かに着手する前に
Netty 入門 - 「Netty ベース」の何かに着手する前に
Takuma SHIRAISHI
継続的インテグレーションとテストの話
継続的インテグレーションとテストの話
Preferred Networks
深層学習生き地獄
深層学習生き地獄
Yusuke HIDESHIMA
Destacado
(8)
(PlayScala(0.9.1) until Play(2.0))
(PlayScala(0.9.1) until Play(2.0))
継続的12章
継続的12章
大崎的デリバリー第2章
大崎的デリバリー第2章
継続的8章
継続的8章
継続的デリバリーを支える開発環境
継続的デリバリーを支える開発環境
Netty 入門 - 「Netty ベース」の何かに着手する前に
Netty 入門 - 「Netty ベース」の何かに着手する前に
継続的インテグレーションとテストの話
継続的インテグレーションとテストの話
深層学習生き地獄
深層学習生き地獄
Similar a 「継続的デリバリー」読書会 第3章 継続的デリバリー
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
Ryutaro YOSHIBA
Cibc lecture imagire
Cibc lecture imagire
Takashi Imagire
TDDBC osaka 2012/06/02
TDDBC osaka 2012/06/02
Hiro Yoshioka
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Rakuten Group, Inc.
Continuous delivery chapter4
Continuous delivery chapter4
favril1
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
shinyatsukasaki
Gamedevenvstudy1
Gamedevenvstudy1
Takashi Kokawa
参加しよう!Hardening Project #h10v #h・v
参加しよう!Hardening Project #h10v #h・v
Masahiro NAKAYAMA
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
atsushi_tmx
ITS fidel
ITS fidel
Fidel Softech P. Ltd
デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)
デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)
Developers Summit
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
Developers Summit
20211221 jasst nano_test automation operation
20211221 jasst nano_test automation operation
Sadaaki Emura
VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0
VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0
Michitaka Yumoto
ALMツールたべくらべ
ALMツールたべくらべ
Kaoru NAKAMURA
Jenkinsstudy#4kokawa
Jenkinsstudy#4kokawa
Takashi Kokawa
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
Rakuten Group, Inc.
Unit testで定時帰宅!
Unit testで定時帰宅!
Funato Takashi
Provisioning & Deploy on AWS
Provisioning & Deploy on AWS
Amazon Web Services Japan
恋するJenkins
恋するJenkins
Hiroshi Nakao
Similar a 「継続的デリバリー」読書会 第3章 継続的デリバリー
(20)
ワンクリックデプロイ101 #ocdeploy
ワンクリックデプロイ101 #ocdeploy
Cibc lecture imagire
Cibc lecture imagire
TDDBC osaka 2012/06/02
TDDBC osaka 2012/06/02
大規模ソフトウェア開発とテストの経験について
大規模ソフトウェア開発とテストの経験について
Continuous delivery chapter4
Continuous delivery chapter4
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
Terraformを活用した自動化デモ_F5-NGINX_Community-20200805
Gamedevenvstudy1
Gamedevenvstudy1
参加しよう!Hardening Project #h10v #h・v
参加しよう!Hardening Project #h10v #h・v
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
Jenkins ユーザ・カンファレンス 2012 東京 S406-4/マルチステージ型継続的インテグレーションのすすめ
ITS fidel
ITS fidel
デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)
デブサミ2014【13-B-L】テスト自動化を見直そう!自動化への投資が開発チームをクリエイティブにする(安竹由起夫〔コベリティジャパン〕)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
デブサミ関西2013【A4】コード品質は曖昧なままか(安竹由起夫氏)
20211221 jasst nano_test automation operation
20211221 jasst nano_test automation operation
VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0
VentureCafe_第2回:SIerでのキャリアパスを考える_ござ先輩発表資料 V1.0
ALMツールたべくらべ
ALMツールたべくらべ
Jenkinsstudy#4kokawa
Jenkinsstudy#4kokawa
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
「最強」のチームを「造る」技術基盤 ディレクターズ・カット
Unit testで定時帰宅!
Unit testで定時帰宅!
Provisioning & Deploy on AWS
Provisioning & Deploy on AWS
恋するJenkins
恋するJenkins
「継続的デリバリー」読書会 第3章 継続的デリバリー
1.
『継続的デリバリー』読書会
第3章 継続的ンテグレーション 大崎的デリバリー @pinori
2.
3.2.1 始める前に必要なもの
1. バージョン管理 • プロジェクトにあるものはすべて単一のバージョ ン管理レポジトリにチェックインしなければならな い – コード – テスト – データベーススクリプト – ビルド・デプロイメントスクリプト アプリケーションの構築・インストール・実行・テストを行 う上で必要なものすべて • どんな小さいプロジェクトでも
3.
3.2.1 始める前に必要なもの
2. 自動ビルド • ビルドはIDEを使わずコマンドラインから実行 できるように – CI環境からビルドプロセスを自動的に実行でき、 何か問題が起こったときに監視できるように – ビルドスクリプトもテストし、リファクタリングする。 – これによって、ビルドの理解や保守、デバッグす るのが容易になる。
4.
3.2.1 始める前に必要なもの
3. チームの合意 • 継続的インテグレーションはプラクティスで あって、ツールではない。 • 故に下記のような規律を開発チームに – インクリメンタルな変更を少しずつこまめにチェッ クイン – 変更によってアプリが壊れたら、それを最優先で 修正
5.
3.2.2 基本的な継続的インテグレー
ション • CIツール例 – CruiseControlファミリー – Jenkins (旧Hudson) – Go (Thought Works Studios社) – TeamCity (JetBrains社) – etc.
6.
3.2.2 基本的な継続的インテグレー
ション • 自分の変更のチェックインの準備が整ったら 1. ビルドがすでに実行されているかを確認。実行中で あれば終了を待つ。失敗したら他のメンバと動くよう に修正。 2. 開発環境のコードをバージョン管理の最新バージョ ンで更新、他人の変更を取得。 3. 開発機上でビルド&テスト。 4. バージョン管理に自分の変更をチェックイン。 5. CIツールがビルド&テスト。 6. 失敗したら、即座に修正して3.へ。 7. 成功したら、次のタスクへ。
7.
3.3 継続的インテグレーションの前提
条件 • CIはプロジェクトの途中から始めようと思うと 多大な苦痛を伴いかねない。 • 始める前に次に上げるプラクティスを準備し ておく必要がある
8.
3.3.1 定期的にチェックインせよ • trunkやメインラインにこまめにチェックインす
べし(少なくとも1日に2回) – 変更は小さくなり、ビルドを壊す可能性も低くなる – 間違った場合にも、元に戻りやすい。 – コンフリクトの可能性も低くなる。 • ブランチを使いながらの本当の意味でのCIは 不可能 – ブランチは他の開発者と統合していないから
9.
3.3.2 包括的な自動テストスイートを作
成せよ • ユニットテスト – コードの振る舞いを個別にテスト • コンポーネントテスト – アプリ内のコンポーネントの振る舞いをテスト • 受け入れテスト – 受け入れ基準のテスト • 機能、キャパシティや可用性、セキュリティ、etc. – アプリ全体を擬似本番環境で起動した状態で実 行するのが望ましい
10.
3.3.3 ビルドプロセスとテストプロセス
を短く保て • ユニットテストの時間が長いと… – チェックイン前に手元でテストするのをやめてしま う – ビルド中に複数のチェックインが行われた場合、 どのチェックインで壊れたのか分からなくなる – チェックインをこまめにやらなくなる • できる限り短くすべき – 10分が限界?
11.
3.3.3 ビルドプロセスとテストプロセス
を短く保て • ビルド時間を減らすために – まず、ユニットテストをより高速に • さらには、テストプロセスを複数のステージに 分けることも – コミットステージ(第7章でより詳細に) • コンパイル • ユニットテスト – 受け入れテストステージ • 受け入れテスト、etc.
12.
3.3.4 開発ワークスペースを管理する • 一般的に開発環境は開発者のローカルマシ
ンに置いておくべき • そのためには… – 自動テストが通り、構成管理されたソースコード、 テストデータ、DBスクリプトなどを取得 – 構成管理されたサードパーティーのライブラリや コンポーネントを取得 – 開発機上で自動テストが通ることを確認
13.
3.4 継続的インテグレーションソフト
ウェアを使用する • 継続的インテグレーションソフトウェアのの最も基本的な機 能 – バージョン管理システムをポーリング – コミットがあれば最新バージョンをチェックアウト – ビルドして結果を通知 • ガジェットで最新のビルドステータスを様々なスタイルで表 示できるので、可視性あげよう – ラバーランプとか音声読上げとか… – ビルドの状態が一目瞭然になる • ちなみに、ビルドの失敗はごく自然なこと – 品質への問題の兆候ではない – 顧客が近いと不安になるかもしれないので、ちゃんと説明すべ し
14.
3.5 基本的なプラクティス • 継続的インテグレーションはツールではなくプ
ラクティス • 開発チームはかなりの規律を守る必要があ る
15.
3.5.1 ビルドが壊れているときには
チェックインするな • ビルドが壊れたら直ちに修正する • 問題が修正されるまでチェックインはしない • さもなければ、 – 問題がより複雑になり、修正により時間がかかっ てしまう – 壊れたままの状態に容易に慣れてしまう
16.
3.5.2 コミットする前に、常にローカルでコミットテストを実
行せよ あるいは代わりにCIサーバーにやってもらえ • コミットする前にバージョン管理から最新版を取得した 上で、ローカルでコミットテスト – ビルドを壊していないかローカルで気づける – CIのコミットメントステージでのエラーは、チェックインし忘 れか、もしくはこの作業中に他人がチェックインしたか • この作業を自動化できるものもある – プレテストコミット、パーソナルビルド、プリフライトビルドな どと呼ばれる – Pulse、TeamCity、ElectricCommanderなどがサポート – コミットテスト終わるのを待たずに次の作業を開始できる
17.
3.5.3 次の作業を始める前に、コミット
テストが通るまで待て • チェックインしたら、ビルドの進捗を観察する 責任が生じる • コミットテストに通るまで、作業を新しく開始し てはならない • ビルドに失敗したらすぐに対応すべし
18.
3.5.4 ビルドが壊れているのに、家に
帰ってはならない • 修正するか、変更を取り消すか • そのためにも、業務終了時間前のチェックイ ンは避ける – チェックインは翌日に持ち越すとか – 万が一失敗しても対応できるように
19.
3.5.5 常に以前のリビジョンに戻す準
備をしておくこと • 問題の修正に時間がかかるようであれば、 – レポジトリをリバート – 問題の解決をローカルで
20.
3.5.6 リバートする前にタイムボックス
を切って修正する • 例えば10分とか決めて、その間に修正できな ければリバートする
21.
3.5.7 失敗したテストをコメントアウトす
るな • 原因を突き止め、以下のいずれかの対応を – コードを修正(リグレッションが見つかった) – テストを修正(仕様が変更された) – テストを削除(テスト対象が削除された) • 一度許すとテストのコメントアウトだらけになり がち
22.
3.5.8 自分が変更してビルドが壊れた
ら、すべてに対して責任をとれ • 自分の変更は他人の書いたテストも通ること – 通らなければ、そのテストも修正を – そのためには、全員がコードベース全体にアクセ ス可能であること
23.
3.5.9 テスト駆動開発 • ユニットテストのカバレッジが十分である必要
がる – 素早いフィードバックのために • そのためにはテスト駆動開発は必須 – お勧め本 • 『Growing Object-‐Oriented SoTware, Guided by Tests』 • 『xUnit Test PaXerns: Refactoring Test Code』
24.
3.6 やったほうがいいプラクティス
25.
3.6.1 エクストリームプログラミング
(XP)の開発プラクティス • 継続的インテグレーションは、XPのプラクティ スのひとつ • 他のプラクティスとの相性もよい • 特にリファクタリング – CIとテスト駆動開発でリファクタリング可能に
26.
3.6.2 アーキテクチャ上の違反事項が
あった場合にビルドを失敗させる
27.
3.6.3 テストが遅い場合にビルドを失
敗させる
28.
3.6.4 警告やコードスタイルの違反が
あった時にビルドを失敗させる • コードチェックツール例 – Simian – JDepend (Java)、NDepend(.NET) – CheckStyle、FxCop – FindBugs • ラチェット方式 – 警告やTODOの数が以前のチェックインより増え ていたら失敗
29.
3.7 分散したチーム • チームが分散している場合のお話
– 物理的に離れている場合 – 時差がある場合
30.
3.7.1 プロセスに与えるインパクト • チームが分散していても時差がなければ、継
続的インテグレーションに違いはない • 時差がある場合は、よりプレセスを厳密に守 る必要がある – ビルド壊れたまま帰宅しちゃうと… • VoIPとかメッセンジャーでのコミュニケーション が非常に重要
31.
3.7.2 中央集権的継続的インテグレー
ション • 1箇所で集中的に継続的インテグレーション – 環境の一貫性を保証しやすい • 開発者がすぐにこの環境にアクセスできるよ うにしておかなければならない – 申請して数日待たないといけないとか…
32.
3.7.3 技術的な問題 • バージョン管理システムとの回線速度や品質
を十分なものに • さもなくば分散バージョン管理システム – GitやMercurial – 回線落ちててもチェックイン可能 • バージョン管理システムと自動テストホスト間 の回線なども大事
33.
3.7.4 代替案 • 中央と太い回線が用意できない場合、バー
ジョン管理システム、CIシステムをローカルに たてる方法もある – 中央と環境を合わせ、同じビルドができるように – ローカルでバージョン管理のためには • コンポーネントベースのアプローチ⇒13章 • 分散バージョン管理システム • 長期的視点では回線を太くするほうが安上が り
34.
3.8 分散バージョン管理システム • 分散バージョン管理システムでCIするには
– 一つのレポジトリをマスターと定め、そこへプッ シュする • GitHubモデルはフォークしたレポジトリが分散 – どれが統合できるかわからない – 変更をすぐにマージ?→たぶん失敗 – 各レポジトリでCI • 変更があったらマスターをマージしてCI • マスターにマージしても正常であることを保証
Descargar ahora