Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
20160128 jjug Nightセミナー_Git実践入門
Search
syobochim
January 30, 2017
Programming
1
1.2k
20160128 jjug Nightセミナー_Git実践入門
syobochim
January 30, 2017
Tweet
Share
More Decks by syobochim
See All by syobochim
AWSで実現する「好き」の感情 / Develop Suki by AWS #devio2022
syobochim
1
330
ドメイン駆動設計のススメ#1 / DDD DevLiveShow Chapter1
syobochim
0
260
ドメイン駆動設計のススメ#2 / DDD DevLiveShow Chapter2
syobochim
0
460
しょぼちむのエヴァンス本のススメ / syobochim read Evans Book
syobochim
9
25k
オンラインのプレゼンがさみしくて 拍手👏アプリつくりました #javajo / ClapHand Application
syobochim
1
280
いちばんやさしいGit入門
syobochim
2
2.8k
KotlinでAndroidアプリつくってみた
syobochim
0
1.2k
第三回マイクロサービスアーキテクチャ読書会(後半)
syobochim
0
1.1k
SIerもはじめる わたしたちのDevOps #jjug_ccc
syobochim
0
1.1k
Other Decks in Programming
See All in Programming
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
d_endo
1
1k
C#/.NETのこれまでのふりかえり
tomokusaba
1
160
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
210
Realtime API 入門
riofujimon
0
110
リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果
katty0324
5
3.6k
RailsのPull requestsのレビューの時に私が考えていること
yahonda
5
1.7k
飲食業界向けマルチプロダクトを実現させる開発体制とリアルな現状
hiroya0601
1
400
ECS Service Connectのこれまでのアップデートと今後のRoadmapを見てみる
tkikuc
2
210
Jakarta Concurrencyによる並行処理プログラミングの始め方 (JJUG CCC 2024 Fall)
tnagao7
1
240
CSC509 Lecture 08
javiergs
PRO
0
110
Content Security Policy入門 セキュリティ設定と 違反レポートのはじめ方 / Introduction to Content Security Policy Getting Started with Security Configuration and Violation Reporting
uskey512
1
440
Webの技術スタックで マルチプラットフォームアプリ開発を可能にするElixirDesktopの紹介
thehaigo
2
930
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
For a Future-Friendly Web
brad_frost
175
9.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
The Art of Programming - Codeland 2020
erikaheidi
51
13k
What's in a price? How to price your products and services
michaelherold
243
12k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
RailsConf 2023
tenderlove
29
880
Product Roadmaps are Hard
iamctodd
PRO
48
10k
The Invisible Side of Design
smashingmag
297
50k
Building Adaptive Systems
keathley
38
2.2k
Transcript
Git実践入門 JJUGナイトセミナー Git入門 2016-01-25(月)19:00 - 21:00
• しょぼちむ • @syobochim • TIS株式会社 こんばんわ!
受託開発 お客様は金融系 基盤チームのメンバーとして案件に参入
結論から言うと 少人数チームでGit導入するのはいいけど 大規模でやるためには 本当にちゃんと運用フローを考えて 体制を整えるか ある程度妥協しないと 大惨事になるということ
※あくまでイメージです
今日は私や、私の周りの人が 案件にGitを導入・運用した時の 開発プロセスについて お話ししていきます
まずソースコードを管理するための 基本的な開発スタイルについて
開発スタイル
構成管理サーバ : GitBucket
CI : Jenkins
mavenリポジトリ : artifactory
ちなみに全部無料!
(Redmine以外は) JVMで動く!
今日はここの話をします
ちなみに全体のざっくりした説明は ↓に書いてます http://syobochim.hatenablog.com/ entry/2015/09/03/214050
GitBucket 構成管理用の リポジトリ管理ツール
GitBucketのいいところ • インストールが簡単 • 無料! • GitHubに似ているから 普段GitHubを使ってい る人には親しみやすい
GitBucketのインストールDEMO
warを直接起動できる!かんたん! ちなみに環境構築についての ブログ書きました http://syobochim.hatenablog.com/entry/ 2015/05/31/232650
https://github.com/gitbucket/gitbucket/wiki/Backup 極たまにデータが飛ぶことがある バックアップを取得しておくことが大事 困ったこと
GitBucketは無償と思えないほど使いやすい! 無償+インストールが簡単なので「とりあえず やってみよう!」の ハードルが低い ただ、トラブル対応などで 導入・運用のコストはかかってしまうので 可能なら最初から有償ツールを 検討した方がいいかも
プロジェクトの構成とブランチモデルについて
プロジェクト構成やブランチモデルは プロジェクトの体制や要員のスキルに 合わせて一番検討する必要があります
• ケース1 ‣ 小規模で構成管理の大切さを知っている人 が各拠点に一人はいる体制 • ケース2 ‣ 小〜中規模でGitを知らない+構成管理につ いて知らない人たちがほとんどを占める体
制 • ケース3 ‣ 中〜大規模でGitを知らない+構成管理につ いて知らない人たちがほとんどを占める体 制
ケース1 • アプリチーム2つ×基盤チーム1つ • プロジェクトの体制は小規模(1チーム10人未満) • アプリチームも基盤チームも主体的に行動している • 基盤チームはアプリ開発への影響を理解している •
アプリチームは基盤部品の重要度を理解している • 必要な基盤部品の提供時期がアプリチームの計画とマッチして いる • 構成管理についてある程度のスキルや知識をもっている人が各 チームに一人はいる
プロジェクト構成 • チームや拠点ごとにリポジトリが分かれるようにする • 画面・バッチ・基盤ごとにチームや拠点が分かれている • ベースリポジトリとサイトリポジトリに分けている
ベースリポジトリ • ライブラリアンのみmerge / pushする権限がある • リリースしてもいいソースのみを格納する
サイトリポジトリ • 拠点ごとにリポジトリを分けている • 各開発者が直接push / pullする
サイトリポジトリ 開発拠点は違うが同じフレームワークを使う場合は 共通用リポジトリから更にリポジトリをforkさせていく fork
ブランチ • 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • pull request形式でレビューをする • サイトリポジトリのmasterブランチへのマージは責任者がやる • ベースリポジトリへのマージはライブラリアンがやる
いいところ リポジトリごとにpush権限を変更できるので 「あっ!間違えてpushしちゃいました!」 というミスをシステム的に防ぐことが出来て安全 自分たちがどのチームにいて 何を開発しているのかが明確になる フレームワーク用にリポジトリを分けているので 自分たちの好きなタイミングでフレームワークの変更を 取り込むことができる 拠点間でのビルドの失敗が他の拠点に影響を与えない
他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい
いまいちなところ 運用コストが高い フレームワークの変更の取り込みタイミングを 各拠点に任せるので 「後でいいや」って思い続けられると死ぬ
ケース3つのまとめ ケース1 運用コスト × フレームワーク変更 の取り込む速さ △ フレームワーク変更 の取り込みタイミン グを決められる
◯ リリース成果物への 権限設定 ◯ レビューしたものの み成果物に出来る ◯ 所感 重厚
ケース2 • アプリチーム複数×基盤チーム1つ • プロジェクトの体制は小〜中規模 • 構成管理についてあまり知識がない人ばかり
プロジェクト構成 • 画面・バッチ・基盤ごとにモジュールが分かれている • ブランチ単位で開発拠点やリリース用ソースを分けて いる
プロジェクト構成 • リリース用のブランチを作って、そこからリリース成果物を 作成する • 開発者はリポジトリに対して直接pull / pushをする
ブランチ • 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
ブランチ • 開発者はfeatureブランチを作って開発をする • 1リポジトリに開発拠点が複数ある場合はdevelopブランチを分ける • pull request形式でレビューをする • masterブランチへのマージはライブラリアンがやる
いいところ 自分たちがどのチームにいて 何を開発しているのかが明確になる フレームワークの変更をdevelopにmergeするので 素早く変更を反映・取り込むことが出来る 拠点間でのビルドの失敗が他の拠点に影響を与えない 他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい
いまいちなところ 「あっ!間違えてmasterにpushしちゃいました!」 というミスがたまに発生する フレームワークの変更の受け入れタイミングを アプリ開発者が自発的に決められない (もちろん事前に調整することが前提)
ケース3つのまとめ ケース1 ケース2 運用コスト × △ フレームワーク変更 の取り込む速さ △ ◯
フレームワーク変更 の取り込みタイミン グを決められる ◯ × リリース成果物への 権限設定 ◯ × レビューしたものの み成果物に出来る ◯ ◯ 所感 重厚 無難
ケース3 • アプリチーム1つ×基盤チーム1つ • プロジェクトの体制は中〜大規模 • アプリチームは完全にオフショア開発 • 構成管理についてあまり知識がない人ばかり
プロジェクト構成 • 画面・バッチ・基盤ごとにモジュールが分かれて いる • ブランチ単位でリリース用ソースを分けている
ブランチ • svnと同じdevelopブランチへの直接commit • masterブランチへのマージは受け入れ時にやる • 基盤チームはパターン2と同じブランチのフローで開発
いいところ 教育・運用コストがかからない フレームワークの変更をdevelopにmergeするので 素早く変更を反映・取り込むことが出来る 他の会社からのソースコード受け入れ時に 対象ソースが何かがわかりやすい (契約によっては開発フローを強制出来ないので 相手のやりやすいように開発してもらう)
いまいちなところ 「あっ!間違えてmasterにpushしちゃいました!」 というミスがたまに発生する フレームワークの変更の受け入れタイミングを アプリ開発者が自発的に決められない (もちろん事前に調整することが前提) レビューしていない成果物が リリース対象に入ってしまう可能性がある
ケース3つのまとめ ケース1 ケース2 ケース3 運用コスト × △ ◯ フレームワーク変更 の取り込む速さ
△ ◯ ◯ フレームワーク変更 の取り込みタイミン グを決められる ◯ × × リリース成果物への 権限設定 ◯ × × レビューしたものの み成果物に出来る ◯ ◯ × 所感 重厚 無難 不安
導入・運用してみて思った事
ガイドを用意するとスムーズ ググったらわかるので皆さん調べてください! ではなく、ガイド化してあげると受け入れられやす い エンジニアならコマンドくらい使えろ!じゃなく プロジェクトメンバーが使いやすいと思うツールを 選んであげる事が大事 ちなみに、ガイドをGitHubで公開しています http://syobochim-doc.readthedocs.org/ja/ latest/index.html
ややこしいことはさせない 必要最低限な操作しかやらせない cherry pickやrebaseなどは、 ある程度知見がたまっている、この人なら安心 できるなーと思う人に「こういうことも出来ま すよ。ただ、こういうところに注意してくださ い」と個人的に教えてあげる方がいいと思う よくわかってない人がよくわからないまま何か すると死ぬ
ある程度の柔軟性も必要 今までのやり方と違うので出来ない!生産性が 上がらない!!という人は絶対数いると思う 『こう使うと、こんなメリットがあってね』っ て説明はしてあげるべきだけど「こうやるん だ!!」って強制すると「うまくいかない!全 てGitが悪い!!」って思っちゃう人もいて、 自分が疲れちゃうので 「じゃあ、そちらのチームとこちらのチームで 使い方変えましょう」くらいの柔軟性も必要
とにかくやってみるとイイ 私はGitをお仕事で使ったことなかったし、GitHub もブランチ切ったりしたことなかった でも導入・運用してみたら、辛いこともあったけど なんとかなった 運用についてのドキュメントや相談相手がチーム外 にでもいると、より安心して運用できると思う なお、今日お話ししたケース1の事例詳細はドキュ メントにまとめられてる https://www.gitbook.com/book/uga/mastering-
builder/details
改善が必要だと思うこと
featureブランチは息短めにする featureブランチが長生きすると、コンフリクト したり共通部品をうまく使えなかったりと、め んどうなことが起こりやすくなる 注意喚起はしているけど、実際何週間もfeature ブランチで開発し続けている人がいるので、解 決策募集中!! ちなみに「syobochim/XXX」のようなブランチ名 になっていたら息が長くなる兆候なので即刻や めさせる
できれば最初にデモしてあげる たまに、「えっ?!そんな使い方してたの?!」って 人がいるので、最初に実際の開発フローがイメージで きるようにデモしてあげればよかったと思う
ちゃんとトレーニングを重ねていく 継続して改善していくためには ちゃんとしたトレーニングが必要 sandboxやhandsonを使って開発者が自由に触 れる環境で遊んでもらうことで Gitに慣れてもらう+使い方を知ってもらえ ればよかった
ありがとうございました
One more thing… created by @kawasima http://unit8.net/gq/