CakePHP2アプリケーションをCapistranoでデプロイする
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
PHP 開発環境は結局こうなった
色々試行錯誤したんだけど、最終的に今回の開発は、以下のような環境で進めることにした。 環境とか VMware Player 2.5.2 Eclipse 3.4 PHPUnit Selenium RC Subversion 1.5系 開発用サーバ 開発用サーバはVMware Player上にCentOS5.3をインストールして、必要なミドルウェアの設定を行ったものを用意した。 VMwareの共有ディレクトリ機能を利用し、/mnt/hgfs/ディレクトリに、チェックアウトしたレポジトリのtrunkを割り当ててある。 レポジトリの構成については、以前Postしたようにtrunk以下に全てのソースコードやドキュメント、ツールが配置されている。 本番と同様のファイル配置にするために、/mnt/hgfs/以下の各ディレクトリに対してシンボリックリンクを張って同じ構成にしている。 この場合ファイルのパー
CakePHP2のbakeコマンドを拡張する方法
CakePHPの良いところの１つに、bakeコマンドでどんどん自動生成していける点があります。簡単なcrudなんかはbakeしてちょっとデザイン変えたりすれば、すぐにでも使えるレベルです。とはいえ、標準のbakeでは以下のような問題があります。 標準ではcrudだけで、index()、add()、 edit()、view()、delete()しか作ってくれない何もプラグインを使わない形になっていて本当に最低限のことしかやれない例えば出力の形式もhtmlだけで、json形式での出力の出し分けとかも自分で書かないといけないしかも出力されるテンプレートファイルのhtmlタグがあんまりいけてない（特にcssのクラス指定のところとか）出力されるコードのインデントやコメントの付け方が好みじゃない毎回標準のbakeを使って生成した後に手で同じところを直すのはDRYではないので、今回は自前でbakeをカス
CakePHPのアプリのコーディング規約チェックを自動で行う方法
みなさんこんにちは。@ryuzeeです。 PHPで書かれたソースコードがコーディング規約に準拠しているかどうか確認するには、PHP_CodeSnifferというツールを使うのはよくご存知だと思いますが、今回はCakePHPを使って書いたソースコードの規約をチェックする方法を紹介します。 なお、このような規約チェックはローカル環境で気が向いた時にやるだけではなく、継続的インテグレーションにも組み込んで実施することが望まれます。 PHP_CodeSnifferのインストール特にチャンネルの追加は必要ありません。 インストールが完了すると、phpcsコマンドがインストールされます。 また標準では、Squiz, PEAR, Zend, MySource, PSR1, PSR2 , PHPCS の7個の規約がインストールされます。このうちMySourceは自分でのカスタマイズ用です。 CakePHP
スクラムの概要を1分で理解できるイラスト【2018版】
みなさんこんにちは。@ryuzeeです。 アジャイル開発のコーチングやトレーニングでスクラムの全体像を1枚の絵を使って説明することが多いのですが、以前作成したものを最新化したので公開します。 スクラムの本質的な価値やスクラム以外でも日々のプロセスに組み込んだほうが良いこと（テスト自動化や継続的インテグレーション）は含めていません。 あくまでスクラムの概要のみを書いています。 PDF版はこちらにおいておきます。 ※改変なしで引用元併記の上であれば自由に使っていただいて結構です。著作権自体は私に留保します。 内容の誤りや足りない事などがありましたらTwitterなどでお知らせください。 自分のスライドに入れて使うためのパワーポイント版はこちらになります。 著作権表示なしでご利用いただけます（ただしこのファイルを含んだパワーポイントの再配布および販売はできません）。 それでは。 SCRUM BO
ウォーターフォールの方が楽ですか？
(顧客) そのシステムを作った結果に対して、顧客自身が結果責任を背負っていない場合は、ウォーターフォールの方が楽。最初に仕様合意して最後に「納品」されれば良い。場合によっては、システムによって得られる価値が目的なのではなく、「システムを作る」こと自体がアリバイ的に目的であるケースすらある。こういう場合は、顧客自体のプロジェクトへの参画が必要なアジャイルは面倒だと思うだろう(顧客) また、顧客が開発部隊に対して政治的に極めて強い力を持っている場合なんかは、基本的に全てのリスクを政治的な力によって移転できるので顧客側が大きくコミットする必要性はなく、ウォーターフォールの方が彼らにとっては楽かもしれない(顧客) その一方で顧客自身が結果責任を背負っている場合やそのシステム自体がビジネスの中心を担っているような場合、肉体的ではなくリスクマネジメントとして楽なのは圧倒的にアジャイルであると言える。市
ふりかえりが失敗する10の要因
みなさんこんにちは。@ryuzeeです。 10 Ways to Kill Your Retrospectiveという記事で、失敗するふりかえりについて、要因のリストが紹介されていたので、抜粋・意訳にてご紹介します。 そもそもふりかえりは自分たちのプロセスの改善のために行うのであって、ふりかえりを行うこと自体は目的ではありません。 ただし、うまくいかないチームを見ていると、問題は出せるが、具体的なアクションに落とせていないとか期限を切っていないためにずるずるやるやる詐欺になっていたり、もしくはあまりに大量の問題が出てしまいチームが諦め気味になってしまったりすることが多くあります。 少しづつでも改善していくことに価値があるので、たとえば、KPTというフォーマットで常にやらなければならないわけでもないですし、いつもと違う場所でやっても構いません。 1. 何も準備していないNG : スクラムのミー
開発をより良くしたい人が読んでおくべき10冊
アジャイルな開発の導入支援の現場や色々な勉強会でよく「どんな本を読んだら良いですか」と聞かれたりします。 何のために本を読んで勉強するかは人それぞれですし、自分のおかれたコンテキストでどの本が役にたつかは分からないですが、以下にあげた本は個人的に強くオススメできる本です。人に聞くのも大事だし自分で試行錯誤するのも大事だけど、本を読んで体系的に学んだり先人の知恵を学ぶことは続けたほうが良い。 プロダクティブ・プログラマ -プログラマのための生産性向上術どうやったら自分自身の生産性を高くすることができるのか。PCの使いこなしから始まり、自動化やバージョン管理等にも触れている プロダクティブ・プログラマ -プログラマのための生産性向上術 (THEORY/IN/PRACTICE)著者／訳者：Neal Ford、島田 浩二 (監訳)、夏目 大出版社：オライリージャパン発売日：2009-04-27単行
大きなリリースの際にチェックすべき34のこと
以前に作っておいた大きめなリリースをする際にチェックしておくべきことのリストが役に立ちそうなので公開しておきます。 僕の場合は普段はワンクリックデプロイが多いんだけど、かなり大掛かりな変更をするケースが年に数回あったりするので、その際にこういうリストを使ってリリース計画をチェックしています。(もちろん大掛かりなリリースでもワンクリックでできるのに越したことはないし、そもそもビッグバンリリースにならないようにできるだけ小さい単位で頻繁にリリースできるに越したこともない) 体制当日の体制は決まっているか夜間立会いの場合、日中の営業時間の対応体制は決まっているか翌営業日以降の体制は決まっているか連絡担当と作業担当は分離されているか作業担当はペア作業になっているか。作業者と確認者を定めているか顧客の連絡先を抑えているか顧客の連絡順番を抑えているか、お客様の当日の所在を抑えているか顧客への連絡タイミ
カンバンを導入する正しい理由5個
みなさんこんにちは。@ryuzeeです。 前回の投稿の続きです。 今度はMichael Dubakov氏が5 Right Reasons to Apply Kanbanということで、正しい導入理由5個について説明していますので、抜粋・意訳にてご紹介します。 カンバンを導入する正しい理由5個 1. いつでもリリースできるようにするスクラムやXPではイテレーションの途中でリリースすることはできない。 カンバンであればいつでもリリースできるかもしれない。 ユーザーストーリーの準備ができたたら、それをリリースする。 このような開発プロセスを作ることは挑戦的だろう。 このような開発プロセスでは、フィーチャー単位でソースコードレポジトリのブランチを管理し、頻繁にマージや結合やテストを行う必要がある。 ただこうすることで頻繁にリリースすることができるようになるのだ。 これはやってみる価値がある。 プロダ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
