nanapi勉強会 vol4 #nanapi_study の参加記録その1 「nanapiの開発フロー」

↓に行ってきました。

nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper

内容とその感想

 

会場の雰囲気

場所は渋谷駅新南口近くという、大変奥まった場所

19:30開始予定で19:00着だったけど、既にいたのは5人だけでした。

参加者としては私服の若い人が多い印象。

ソフトウェア品質シンポジウムとは全然違うね!

 

オープニング

この勉強会の経緯 

 

 

 ということで、合同開催。

9日には京都でもやるみたいです。


【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass

 

nanapi IGNITIONチームの開発フローとその構築

発表者は@vexus2さん

PHP好き。

nanapiのサービス

  • nanapi
  • answer
  • IGNITION ←今回語ってもらったのはこのチーム

スクラム開発

前までは物理かんばんだった

メリット

  • 一貫性がある

デメリット

 

  • デジタルとアナログの2重管理
  • 移動がめんどい
  • ログが残せない

 

Pivotal Trackerを導入

 

  • 優先度付けが楽
  • フローがシンプル
  • Githubとの連携が楽

 

開発方法

github flowに従う

masterブランチは常にリリース可能な状態に

ワナ

ルールに縛られるのではなく、例外を持とう

例えば、レビューする人が長期休暇を取ったら、その間はリリースできないのは良くない!

  • テストがあればリリースOK
  • CSSやHTMLの些細な変化はそのままリリース

ツール - Circle CIを導入 -

  • スペックが高い
  • SSHでアクセス可能

 

なぜJenkinsを使わないのか

  • メンテコストが高いから
  • メンテナーが固定されるから(Jenkinsおじさんが必要)

メンテナーが置ける組織だったら、Jenkinsという選択はあり

 

開発フロー構築について

チームに最適なものを選ぼう
  • 個人の好きなように欲張らないこと
  • サービスがグローバルを目指しているため、グローバルスタンダードを重視した
社内のエバンジェリストになる
  • 丸投げしない

例)Slackを使う時

  • 自分が使う
  • ドキュメントが英語しか無かったため、日本語にまとめる
 現状に満足しない

 

はてなの開発フロー

 は、ここまで書くのに疲れたので、また次回