RedmineとGitLabを使ったソフトウェア開発プロセスの紹介

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は機能がダブるので
棲み分けに工夫が必要