Recommended
More Related Content
What's hot
What's hot (20)
Similar to 怖くないブランチ開発外部公開用
Similar to 怖くないブランチ開発外部公開用 (20)
More from CROOZ, inc.
Recently uploaded
Recently uploaded (8)
怖くないブランチ開発外部公開用
- 2. © CROOZ,Inc. 2 本日の内容 ・ ブランチという概念 ・ ブランチ開発の必要性 ・ 避けては通れないマージ ・ なぜvenus 3.0以降ではGITか？ ・ venus 3.0での開発フロー ・ GITを利用する場合のクライアントツール ・ DEMO ・ まとめ
- 3. © CROOZ,Inc. 3 １．ブランチという概念 その前に、なぜバージョン管理 ツールが必要なのか？ 当たり前のこととして片付けられているのか 意外と記事がないので、改めて考えてみま しょう。
- 9. © CROOZ,Inc. 9 ０．何故バージョン管理が必要なのか ただ以下の疑問がある人いませんか？ うちのチームはバージョン管理ツール入れて るんだけど、よくデグレ起こるんだよなぁ… 何故か？ 大きく分けて原因は２つです ・ 実は作業開始前の手元のソースコード が最新ではない。 ・ マージが適切に行えていない。
- 10. © CROOZ,Inc. 10 ０．何故バージョン管理が必要なのか 実は作業開始前の手元のソースコードが最新ではない 例） 作業対象のソースコードがサーバ上で更新されて いることを知らずに、手元のソースコードが最新だ と思い込んで修正を行い、サーバに更新してしま った。 マージが最適に行われていない 例） 本来ならばサーバ上のソースコードに修正内容を 追加しなければならないところを、間違えて追加を せずにサーバ上に更新してしまった。 この２つが組み合わさるとデグレがおこる
- 12. © CROOZ,Inc. 12 １．ブランチという概念 話を戻して ブランチとは「枝・分岐」のこと 変更１ 変更２ 変更３ 変更３’ 変更４ 変更４’ ブランチ タイムライン
- 13. © CROOZ,Inc. 13 １．ブランチという概念 例えば、あるサイトを作っていて「ちょっとだけ違う」サイト をBP向けに作ってくれと言われたら貴方はどうしますか? ソースコードをコピーし、別のサイトのリポジトリとして 管理しようとすると以下課題があることに気づきます ・ コピー元のサイトのバグFIXが適応されず、わざわざ コピー先のサイトに反映しなければならない このような時に「ブランチ」という概念が重要となります。 特定のバージョンからブランチとして枝分かれさせること で、枝分かれする前のバグFIXを２重に管理しなくても 良くなります。
- 14. © CROOZ,Inc. 14 １．ブランチという概念 つまり、 「一つの開発の流れが、もう一方と独立して 存在しているが、 もし過去にさかのぼれば 同じ履歴を共有している」 というのがブランチの概念です
- 15. © CROOZ,Inc. 15 ２．ブランチ開発の必要性 チーム開発をしていると以下のようなことはないですか？ ・ 複数の機能を並行して同時に開発しなければ ならなくなった ・ 開発していた機能のリリースが見送られ、次に 開発する機能がリリースしてからとなった ・ バグFIXと機能開発が並行して行わなければ ならなくなった このような時に、ブランチ開発の必要性が出てきます
- 16. © CROOZ,Inc. 16 ２．ブランチ開発の必要性 ブランチ開発を行うこと バグFIX1 機能開発１ バグFIX2 完了 タイムライン 機能開発２ 完了 リリース リリース 複数の開発案件を同時に行うことができる 開発順どおりに リリースしなくて もよくなる
- 17. © CROOZ,Inc. 17 ２．ブランチ開発の必要性 ・ 案件を直列にしか行えなくなる ブランチ開発を行わないと… ・ 無理やり行えば並行に開発できるが、デバッ グがかなり面倒なことになる 結論 複数の案件を並行で動かす現場において 開発スピードを上げたければブランチ開発 が必須。 理由 開発工程のうち、必ず直列でしか行えない 個所がボトルネックとなるから
- 19. © CROOZ,Inc. 19 補足 ブランチはバージョン管理上の概念です。 従って枝分かれしたソースについてはそのままではweb 上で確認できず、リポジトリから出力しweb上から見れる 用にWebサーバの設定を変更する必要があります。 そして、この一連の作業を仕組みとして自動化している のはVenus 3.0以降です。 チーム開発が想定されるプロジェクトで、開発スピードを 向上したいのであれば、venus3.0以降を採用して下さい
- 21. © CROOZ,Inc. 21 ３．避けては通れないマージ まず、マージは必ず必要があります なぜなら、リリースできないから リリース対象は枝分かれする前のものなので、元の主流 に戻してあげないリリースできない 変更１ 変更２ 変更３ 変更３’ マージ 変更４’ タイムライン リリース対象 作成したブランチ 当たり前だが、マージしない限り反映されません
- 27. © CROOZ,Inc. 27 ４．なぜvenus 3.0ではGITか？ 補足でも説明した通り、venus 3.0からブランチに格納さ れているソースコードについてもが行えるWebサーバ上 から確認できる仕組みをフレームワーク上で提供してい ます。 ただし、これはフレームワークの機能であり、バージョン 管理ツールへの要件はブランチ管理が行えることです。 そして、その要件はGIT以外もSVNでも満たすことがで きます。 枯れ切っているSVNではなく覚え直してまでもGITが前提 となっているのか？
- 28. © CROOZ,Inc. 28 ４．なぜvenus 3.0ではGITか？ いくつかの理由があります。ここで重要なのは ・ プロトコルが速い ・ 分散アーキテクチャ ・ ブランチ開発が行いやすい ・ マージが容易 ブランチ開発を行う上で気を使うところはマージです なぜならここを失敗すると間違った内容がリポジトリに保 管されてしまい、苦労して作成したソースコードが一瞬で 消えてしまうからです
- 29. © CROOZ,Inc. 29 ５．venus 3.0での開発フロー ロ ー カ ル 環 境 ①Eclipse等で開発 ②ローカル上で確認 http://blog.ローカルドメイン名 ③ローカル環境 にcommit dev 環 境 ④workブランチに push ⑤ワークブランチ上で確認 http://work.dev3.ドメイン名 ⑦masterブランチに push ⑧マスターブランチ上で確認 http://dev3.ドメイン名 work ブランチ master ブランチ ⑥ローカルでwork→master にmerge ・ローカル⇒dev devには２つのブランチが存在
- 30. © CROOZ,Inc. 30 ５．venus 3.0での開発フロー ・ローカル⇒dev masterブランチ リリース対象（このままプレで検証し、本番に反映する） となるブランチ。（http://dev3.ドメイン名/） workブランチ 開発時のテスト用ブランチ ローカルでテストした後にAPI連携などを確認するため のブランチ。（http://work.dev3.ドメイン名/） その他ブランチ 開発用に個別でブランチを作成可能 確認後必ずローカルでmasterブランチにマージ してからdevのmasterブランチにpushすること
- 31. © CROOZ,Inc. 31 ５．venus 3.0での開発フロー ・devから⇒本番 dev 環 境 master ブランチ プ レ 環 境 master ブランチ ⑨プレ環境にpush ⑩プレ環境で確認 http://pre3.ドメイン名 本 番 環 境 ⑪本番環境にsync ⑫本番環境で確認 http://blog.crooz.jp プレ以降は変更なし。 devからプレは、venus 2.0のようにローカルから プレ上のリポジトリへの更新ではなく、dev上で pushすることにより反映します。
- 32. © CROOZ,Inc. 32 ６．GITを利用する場合のクライアントツール ・Windowsの場合 ・Git Bash コマンドラインツール ・TortoiseGit TortoiseSVNのGIT版 ・Git Extensions GUIツール お勧めは、Git BashとGit Extensions TortoiseGitはpushのオペレーションがわかりづらいの、コミットグラフがわかりづらい ・Macの場合 Source Tree
- 33. © CROOZ,Inc. 33 ６．GITを利用する場合のクライアントツール Git Extensionsを利用する際の注意点 ・インストールの際に必ずGit BashとKDiff3を一緒に インストールすること ・KDiff3の文字コード設定は必ずUTF-8で行ってくださ い