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

そこに仁義はあるのか(仮)

略してそこ仁!

これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ!!

受託開発やっている、いまの開発スタイルを書く。

この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。(書く順番が逆っぽい)
今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。

f:id:syobochim:20160923155657p:plain

バージョン管理はGit

プロジェクト用サーバーにGitBucketをたててソースコードを管理している。
オフショアと仕事をするなど、開発拠点がわかれることが多い。
ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。
各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。
弊社の”エンジニア”はみんな当たり前のようにGitを使っている。

受託開発的に、ソースコードを社外に配置するのはのは結構ハードルが高い+運用にお金がかかっちゃうとマネージャを説得しなければならなくて無駄にHPが削られるので、
そういった無駄な労力を避けるために、プロジェクトメンバーのみがアクセス出来るサーバにGitBucketをたてている。
GitBucketの立て方はブログ書いた

CIは必須

顧客が急に動作確認したいと言いだすこともあるので、ソースコードは常にデプロイ出来る状態にしておく必要がある。
GitBucketをJenkinsで常に監視している。
GitBucketに対してソースがpushされたら、それをpullして、最新のソースに対してテストやデプロイを行っている。
JenkinsとSonarQubeの連携を行っていて、ソースコードの品質を常にチェックしている。
SonarQubeの説明はこれがわかりやすい:SonarQubeでプログラムの品質管理をはじめる(概要) - Qiita

なお、うちのプロジェクトは諸事情ありまして、JenkinsとSonarQubeはWindows7 PCに立ててる。
JenkinsとSonarQubeの構築手順のはなしは需用があればブログ書きますー。
ただ、プロキシ的なところではつまづいたけど、それを除けばサラッと構築できてしまったので、アレ。

ライブラリ管理はリポジトリ

jarファイルや.classpathや.projectファイルがバージョン管理リポジトリに配置されているのは既に過去。
プロジェクトの各モジュール間やフレームワーク、ライブラリの依存関係はmavenで定義している。
プロジェクトごとにリポジトリ管理ツール(Artifactory)を構築している。
この記事でいま開発をすすめていくなかでの各モジュールの位置づけを書いているけど、parentとかcoreとかentityモジュールに関してはこちら側で修整+提供をしている。
それを、Jenkinsでビルドして、ビルドの後処理でプロジェクトのArtifactoryにdeployしている。
開発者は必要なjarをプロジェクトのArtifactorymavenセントラルからダウンロードして開発していて、個人が自分のローカルにこっそりjarファイル置いていて、コミットしたら動きませんなんてことが全くない。

それによって、各開発者は常に最新のjarをリポジトリから取得することが出来る。

開発の早い段階でバージョン固定したjarを管理してるから、古いモジュールを意図的に使うことも可能なので、
依存関係のある他モジュールを変更した!⇒動かなくなった!
なんてことはなく、新規開発するひとは新しいモジュールで開発するし、既存のソースコードは一旦古いモジュールのjarを参照したままにしておいて、修整や動作確認ができたら新しいモジュールに切り替え、が簡単に出来る。

課題はチケット管理

Redmineで課題や別拠点とのQAの管理をしている。
Redmineからエクセルを出力して顧客に見せているので、SIer的にも安心!
Redmineで課題を管理することによって、課題の関連付けがさっと出来るし、自分の担当チケットなんだっけ?という検索もサッとできる。
課題の証跡や残課題の総量もわかりやすい。

気軽にコミュニケーションをとるときはチャット

リモート拠点の開発者とのコミュニケーションにチャット(back-channeling)を導入した。
まだ導入したてだけど、Redmineでのチケットを切るほどでもないけど、電話やメールがめんどくさい、というときにチャットあるの便利。

コミュニケーションの回数は増えたけど、1つ1つの粒度は小さいし、ふだんはおとなしい開発者の人からも、こういうふうにした方が良いんじゃないですか?的な提案が来たりした(!)ので、今のところかなり満足度高い。

なお、使ったのはコレ。話題がスレッド形式で、話題単位でページが別れるのもイイ。
github.com


なお、このチャットの説明はこちら:BackChannelingによるお手軽お仕事用チャット - Qiita

何がイイって

ツールとしては全部タダだし、情報が中にクローズされているのがイイ。
やっぱり、お金かかっちゃったり、ソースコードを外に置いたりするとなると、マネージャーや顧客を説得するという無駄な消耗が必要になったりする。
自前で構築や運用をやらなきゃいけないんだけど、Redmine以外はJVM上で動くのでセットアップもちょー簡単だし、それで自分が快適になるので全く苦じゃない感じある。

@さんが同じ部門になって、この開発スタイルが弊社のデファクトスタンダードになっており、かなりイイ。

とりあえず新人さんはこれ読んどけばいいんではないですかね。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)