最近、ちょうど頭の中で考えている開発の手法だとか運用方法だとかがクックパッドの開発ブログで文章化されているので、人に伝えるときにとても重宝している。

というわけで最近の3記事は直近で見直したり見せたりすることがありそうなのでメモ。

"使える"プロトタイプ主導の開発プロセス - クックパッド開発者ブログ

ペンとふせんで!スマホUIのアイデアプロトタイピング - クックパッド開発者ブログ

iOSアプリの継続的デリバリーへの取り組みについての勉強会を開催しました - クックパッド開発者ブログ
[PR]
by yamacraft | 2016-10-17 22:34 | いろいろ
[速報]Docker Hub発表。ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。Dockerのプラットフォーム化を推進 - Publickey

現状はDocker Hubはどういうふうに提供されるのとか、どこまで出来るのかといった部分がつかめていないのですが、上の記事にあるように、GithubやBitbucketにソースを置いて、そこからビルド+テスト+デプロイをDocker Hubでできるようになれば便利かなあと。

会社での話は置いておくとして、個人開発でそれなりにいい感じの管理や自動化をさせようとすると、ちゃんとしたサーバを用意するとか、ツールサービスを利用する方法があるわけですが、自分の場合は

- 開発環境はお馴染みのMSI U-100+xUbuntu12.10
- ソースコード管理はBitbucketのプライベートリポジトリ(月額無料)
- 自動ビルドは格安VPSにおいたJenkins(月額1000円)
- 配布はDeployGate経由(月額無料アカウント利用)

という形をとっています。
ここでキモになるのは自動ビルドのJenkinsで、本当はテストもここでやりたいわけなんですが、格安VPSのサーバーではUbuntuサーバ版で動かしているのでエミュとかGenymotionが動かないため、やむなくテストは開発環境上で行っています。
最近はtravisCIがandroid対応しているようですが、travisCIはプライベートリポジトリの利用は有料という難点があります。

ケチと言われるとそれまでなんですが、個人的にはやればやるほど損をするシステムになってしまうと、そもそものモチベーションが下降する一方になってしまうので、それならまだ制限が掛かってるほうがやりがいがあります。
昔から開発って、何かしら制限がある中でやっていたので、そういうのは気にならないです。

できれば作ったアプリの広告収益が安定するようになれば、それを元にVPSをもう少し上のアカウントに変えるとか、それこそtravisCIを使ってみるとか、Githubの有料アカウント登録をするとかできるわけなんですが、現実は1年前から「規定額を満たしていないので振込は来月分に回します」メールが毎月Adから届いている状況です。

厳しいですね。Docker Hubは無料でJenkinsにとって変わるサービスであればいいなあと期待してしまいます。
[PR]
by yamacraft | 2014-06-10 23:15 | いろいろ
先日、社内ワークショップに参加したときにGitを使った運用フローの話になったんですが、「決まった形でブランチを切ることがGit-flow(Github-flow)の本質じゃない」みたいな感じのことを言われて、そういえば確かにそれぞれの運用フローを「どうブランチ切るか」でしか見てなかったなあと気がついたので、改めて調べることにしました。

結論から書くと、まだわかってないです(調べきってないので)。

A successful Git branching model » nvie.com

見えないチカラ: A successful Git branching model を翻訳しました

Gitブランチを使いこなすgit-flow/GitHub Flow入門(1):いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2) - @IT

Git flowの活用事例

git-flow cheatsheet

GitHub Flow – Scott Chacon

GitHub Flow (Japanese translation)

Gitブランチを使いこなすgit-flow/GitHub Flow入門(終):プルリクエスト/レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - @IT

誰得UNIX: git-flowでもgithub flowでもない、Git本家推奨のワークフロー

非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog

ブランチの構造だけみると、GitHub-Flowの方がシンプルで便利そう!とは思うけど、ここで「CI等を使った自動テストやリリース、ドッグフーディングをどう挟むか」になると、意味合いは全然変わってくるのかなと思いました。

GitHub-Flowは構造がシンプルな分、開発ブランチ作るたびに都度自動テストを行うブランチの向け先を変えないといけないのかな、という印象があって、複数の機能追加が行われる状態になると、交わる先がmasterになってしまうのもかなり危うい印象を感じます。
これはWebサイトみたいに1日に大量のデプロイを行うことが可能なWebサイトだからこそ可能なのかな、と思いました。あとテストがしっかり組まれてることが前提で。

逆にGit-Flowは基本master前に一つブランチを挟むので、「テストが甘いのである程度人の手によるテスト期間が必要」とか、「そもそもUIテストやリリース前のドッグフーディングが必要なのでテスト期間いるよ」、みたいなコードフリーズ的な要素がいる場合に有効な手段なのかな、と。

実際には各ブランチでどういう作業をして、CIやデプロイ、QAはどういう形で行うべきなのかっていうのまで調べないと意味がないだろうとはわかっているけれど、実際のコーディング以外のことを考えると、アプリ開発にはGit-Flowの方がやりやすいところは多いのかなと感じました。

develop ブランチなんてオワコン - Togetterまとめ

あとそれを考えた上で、やっぱりGit-FlowのDevelopブランチ不要論は、工場で言うところの「結局みんな怪我しないように気をつけて、実際に事故起きてないから指差し呼称点検は不要だよね」みたいな危うさを感じてしまいました。
自分は人の力を信じないので、あえて一手間かけて意識を向けさせることは重要だなと思っています。
[PR]
by yamacraft | 2014-06-06 22:45 | いろいろ