The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Laravel+Rocketeer+CircleCIの構成でAWSにデプロイする
うぇぶまけ/webmake WebマーケティングとWeb制作に関わる情報や、個人的な趣味の映画鑑賞・書籍の情報を書き溜めていく備忘録 何故やったか 以前、Amazon EC2+Jenkins+capistranoでLaravel5をデプロイするという記事を書きましたが Jenkinsは職人化する Laravelとの相性はCapistrano < Rocketeer ということで、CircleCIと、Rocketeerを試してみました。 概要 ・Rocketeer https://github.com/rocketeers/rocketeer PHP製のデプロイツール。 RubyでいうCapistrano。 Laravelプロジェクトと親和性が高く、各種チャットアプリにも通知が行える。 ・CircleCI https://circleci.com/ 俗に言うCIツール。 テスト・デプロイなど
中の人に聞いたGitHub flowの本当の使い方 - Qiita
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
RailsアプリをNginx+UnicornなAWSにCapistranoでデプロイ - 珈琲駆動開発
Special Thanks Rails 初心者が Capistrano3 で AWS EC2 にデプロイするためにがんばったこと。 RailsアプリをEC2にデプロイしてみる。 - xxxcaqui.log 追記@2016/04/29 最近は環境やconfファイルのsetupはitamaeでやるようになりました。めっちゃ楽ですitamae。。 goo.gl totutotu.hatenablog.com PostgreSQLの設定は、以下を参考にしていつも自分でやってます。 totutotu.hatenablog.com 手順 手順をまとめると、以下のようになります。 前準備 nginxの設定 設定ファイルの用意 権限変更 Capistrano設定 Unicorn設定 ssh設定 デプロイ myAppの部分は適宜読み替えてやってください。また、設定ファイルのうち編集する必要がある場所にT
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
