読者です 読者をやめる 読者になる 読者になる

ユアマイスター株式会社エンジニアブログ

ユアマイスター株式会社のエンジニアが日々徒然。

ユアマイスターの開発フロー

こんにちは。ユアマイスターエンジニアです。 今日はうちの開発フローについて紹介したいと思います。

f:id:yourmystar_engineer:20170310180020p:plain

GItHubとCircle CIを中心にした開発フロー

ユアマイスターでは新規開発をする時にBacklogのチケット単位で担当者をアサインしています。

チケットの粒度は様々で、新規機能追加のような中規模のものもあれば、

バグ修正のような小規模なものもあります。

そこで一番大切にしていきたいのは、

できるだけスピードを落とさずに、

できるだけ品質が高いものを

できるだけ頻度高く世に送り出すこと

「できるだけスピードを落とさず」のために、Circle CIを導入し、デプロイ自動実行をさせています。

(本番環境はまだ導入できていませんが、近いうちに完全導入の予定です)

「できるだけ品質が高いもの」のために、これまたCircle CIでテスト自動実行をさせています。

まだまだエンジニアチームのスキルが追いついておらず、ちゃんとテストコードを拡充できていませんが

ここからのみんなの成長に期待して環境は整えておきました。

そして、「できるだけ頻度高く世に送り出す」のために、僕らは一つのチケットを

さらに要件を切り分けて細分化するようにしています。

流れのポイント解説

ポイント1 基本開発はローカルで!

それぞれVagrant仮想マシンを立て、ローカルで開発ができるような環境を作ってます。

壊れてもまた作り直しが効くので、ローカル内では好き勝手し放題!

ポイント2 Slackにつぶやいてプルリク作成!

以前はGitHubの画面でプルリクを作っていたのですが、

いろんなエンジニアが間違えてmasterへのプルリクを作ってしまい

意図せず本番にリリースされそうになるという事件が何回かおきたので、

必ずdevelopへのプルリクになるよう、手順化を行いました。

Zapierというツールで連携することにより、ブランチ名をつぶやくと

プルリクを作成してくれるBotでミスを回避するようにしています!

ポイント3 個別のブランチはdevelopから作成し、リリースする時だけdevelop->masterマージ!

以前ぼくが働いていたところは、masterからブランチを切っていたのですが、

ユアマイスターではdevelopからブランチを切っています。これは「Git Flow」をベースにしています。

qiita.com

そして、リリースする時にだけ、develop->masterでマージするわけですね。

よくある「GitHub Flow」はmasterからブランチを切りますので、「Git Flow」とはちょっと違います。

ここら辺の話はまた別回にご紹介します!

だからといって今に満足しているわけではない

色々、最近流行っているツール等を導入してみたわけですが、

純粋なエンジニアリングのレベルが上がるわけではありません。

ミスが減ったり、無駄が作業が減ったりする中で、よりものづくりに集中できる環境

近づいたといったほうが正しいと思います。

ここから、チーム一丸となって強い開発組織に成長していきます。