Redmine + gitlab: merge base development
- 1. Redmine + GitLab マージベース開発プロセス 株式会社アピリッツ 島田慶樹
- 2. 2 自己紹介 • RailsでのWebシステム開発6年くらい • Apache Cassandraの導入 • 現在はScala Playframawork
- 3. プロジェクト概要 3 • Webサービスの新規開発（SI案件） • 開発メンバー 6名前後（Rails初心者含む） • 設計からC/Oまで数ヶ月
- 4. 4 ツールまわり
- 5. 5 Redmine • お客様参画プロジェクト • 課題管理（チケット） • ドキュメンテーション（wiki） • 開発者専用プロジェクト • タスク管理（チケット） • ドキュメンテーション（wiki）
- 6. 6 GitLab • リポジトリホスティング • gitアクセス権限管理 • マージリクエスト • ブランチ管理
- 7. 7 Jenkins • 開発ルールとしてRSpec必須化 • メインラインとマージリクエストの ２プロジェクト
- 8. 開発サイクル 8 1. 機能ごとにチケット起票 2. 開発者にアサイン 3. トピックブランチで開発 4. リポジトリにプッシュしてマージリクエスト 5. マージ担当者のピアレビュー、マージ
- 9. 9 チケット駆動開発
- 10. 10 ブランチ戦略 topic 1 develop master merge request! release!
- 11. 11 マージリクエスト
- 12. 12 マージリクエスト reviewee reviewer マジリク
- 13. マージリクエスト 13 メンバーの中から相手を1人選んで マージリクエストを投げる • 関連する機能を作ってる人 • 内容について相談できる人
- 14. 14 マジリクのルール 業務で行う開発の場合、マージリクエストは ! ! では済まされない
- 15. 15 OSSとの違い Pull Request コードオーナー コントリビューター LGTM! オミゴト！
- 16. 16 マジリクのルール • マージリクエストは自分以外の開発者に アサインする • マージリクエストを依頼するチケットを 作成する • チケットに、実装した機能を確認する手順を 簡単に記述する
- 17. 17 確認手順チケット
- 18. 18 マジリクのルール • アサインされた開発者は下記の内容を確認し、 問題がなければマージを実施する。問題があれば差し戻す • テストがついているか、Jenkinsで そのテストがパスしているか • 手順どおりに機能するか • コードのフォーマットや内容に不備がないか • メソッドの長さ、ネストの深さなど
- 19. 評価
- 20. 20 振り返り - keep • developブランチのコードを 常に動作確認済みの状態に保つことができた • マジリクを分担することにより、 他のメンバーのノウハウを吸収できた
- 21. 振り返り - problem 21 • 不具合対応や微調整の時期になると、 マジリクの作成・実施が重くなってきた • 一部のメンバーにマジリクの負担が 集中した
- 22. 22 振り返り - try • 開発のフェーズにあわせて マジリクの運用ルールを調節する • 開発者用プロジェクトをRedmineから GitLabのissue, wikiに移行 ※お客様参画プロジェクトはそのまま
- 23. 23 まとめ • GitLabによるマジリクベースの開発で 結合テストを開発プロセスに織り込む • RedmineとGitLabは機能がダブるので 棲み分けに工夫が必要