Redmine + GitLab マージベース開発プロセス

株式会社アピリッツ 島田慶樹

自己紹介2

• RailsでのWebシステム開発6年くらい

• Apache Cassandraの導入

• 現在はScala Playframawork

プロジェクト概要

• Webサービスの新規開発（SI案件）

• 開発メンバー 6名前後（Rails初心者含む）

• 設計からC/Oまで数ヶ月

3

ツールまわり4

Redmine5• お客様参画プロジェクト

• 課題管理（チケット）

• ドキュメンテーション（wiki）

• 開発者専用プロジェクト

• タスク管理（チケット）

• ドキュメンテーション（wiki）

GitLab6

• リポジトリホスティング

• gitアクセス権限管理

• マージリクエスト

• ブランチ管理

Jenkins7

• 開発ルールとしてRSpec必須化

• メインラインとマージリクエストの２プロジェクト

開発サイクル

1. 機能ごとにチケット起票

2. 開発者にアサイン

3. トピックブランチで開発

4. リポジトリにプッシュしてマージリクエスト

5. マージ担当者のピアレビュー、マージ

8

チケット駆動開発9

ブランチ戦略10

topic 1

develop

master

merge request!

release!

マージリクエスト11

マージリクエスト12

😐

reviewee

reviewer😐 😐

😐

😐😐

マジリク

マージリクエスト

メンバーの中から相手を1人選んでマージリクエストを投げる

• 関連する機能を作ってる人

• 内容について相談できる人

13

マジリクのルール14

業務で行う開発の場合、マージリクエストは

!

!

では済まされない

OSSとの違い15

Pull Requestコードオーナー

コントリビューター

LGTM!オミゴト！

マジリクのルール16

• マージリクエストは自分以外の開発者にアサインする

• マージリクエストを依頼するチケットを作成する

• チケットに、実装した機能を確認する手順を簡単に記述する

確認手順チケット17

マジリクのルール18• アサインされた開発者は下記の内容を確認し、問題がなければマージを実施する。問題があれば差し戻す

• テストがついているか、Jenkinsでそのテストがパスしているか

• 手順どおりに機能するか

• コードのフォーマットや内容に不備がないか

• メソッドの長さ、ネストの深さなど

評価

振り返り - keep20

• developブランチのコードを常に動作確認済みの状態に保つことができた

• マジリクを分担することにより、他のメンバーのノウハウを吸収できた

振り返り - problem

• 不具合対応や微調整の時期になると、マジリクの作成・実施が重くなってきた

• 一部のメンバーにマジリクの負担が集中した

21

振り返り - try22

• 開発のフェーズにあわせてマジリクの運用ルールを調節する

• 開発者用プロジェクトをRedmineからGitLabのissue, wikiに移行※お客様参画プロジェクトはそのまま

まとめ23

• GitLabによるマジリクベースの開発で結合テストを開発プロセスに織り込む

• RedmineとGitLabは機能がダブるので棲み分けに工夫が必要