Deployer - The deployment tool for PHP | Deployer
Deploy PHP everywhere The PHP deployment tool with support for popular frameworks out of the box. Get Started ProvisionDeployer will configure your server, setup a firewall, install PHP and MySQL or Postgres, configure HTTPS, etc. Zero downtimeZero downtime deployments. Did something go wrong? Rollback to the previous release.
シンボリックリンクを用いたアトミックデプロイと opcache と realpath cache - ngyukiの日記
これまで PHP のアプリケーションのデプロイは rsync でどべーとコードを撒いていました。が、それだと新旧のコードが混在するし Capistrano とかはデフォでシンボリックリンク切り替えでアトミックなデプロイになっているし、周回遅れな感じもしますが今後は似たような方法でデプロイしたいと思います。 releases/ ディレクトリの中にリリースタグでディレクトリを掘ってコードを配置して current を最新のリリースのディレクトリへのシンボリックリンクにします。そして Apache や Nginx でドキュメントルートを current の中の公開用のディレクトリに設定します（/path/to/app/current/public とか）。 /path/to/app/ releases/ 20161213/ 20161224/ 20170101/ current -> relea
Deployer + CircleCIでデプロイを自動化する | QUARTETCOM TECH BLOG
新年明けましておめでとうございます、永井です。 本年も「カルテットコミュニケーションズ技術ブログ」共々頑張っていきたいと思いますので、宜しくお願い致します。 はじめに カルテット社内におけるデプロイツールのデファクトスタンダードは、Capistranoです。 機能的には特に不満はないのですが、たまに手の込んだことをやろうとすると途端に躓いてしまった経験が何度かあり、出来ればアプリケーションで利用しているプログラミング言語で良いツールがないかなと思っていました。 そこで今回はDeployerを試してみました。 今回のゴール シンプルなPHPのプロジェクト（Silexベース）をDeployerでデプロイする CircleCIを利用して、 特定ブランチが更新された時に自動的にデプロイする Deployerについて DeployerはPHP製のとてもシンプルなデプロイツールです。 公式サイトを見る
ZDT Deployment for PHP
Zero DownTime (ZDT) Deployment for PHP The majority of modern web-services should be accessible for users at all times. A common but often overlooked problem here is the process of project re-deployment (i.e. update), causing your application to go down or return errors until the operation is finished. This can be solved with a variety of tools like Capistrano, Fabric and others. However, these su
ウォールマートがリリースしたDevOpsプラットフォーム「OneOps」レビュー | さくらのナレッジ
2年くらい前からたびたびDevOpsというキーワードが聞かれるようになっています。開発者と運用担当者、ディレクターなどが一体となって開発から本番環境への反映サイクルを高速化していくという体制を言います。 JenkinsをはじめとしたCIであったり、チャットであったりと個別の技術についてよく聞かれますが、今回はそんなDevOpsを統合的に提供するOneOpsを紹介します。OneOpsはアメリカのスーパーマーケット最大手であるウォールマートが開発している点が特徴となっています。 一番簡単なインストールはVagrantを使うこと 幾つかのインストール方法が紹介されていますが、最も簡単なのはVagrantを使うものです。 git clone https://github.com/oneops/setup cd setup/vagrant cp ~/.ssh/id_rsa git_ssh/git_r
EC2でphp環境構築 ② gitサーバー構築 + altax導入 + デプロイコマンド作成 - Qiita
[ec2-user@ip-172-31-4-XXX ~]$ sudo useradd -m -s /bin/bash gituser [ec2-user@ip-172-31-4-XXX ~]$ sudo mkdir /home/gituser/.ssh [ec2-user@ip-172-31-4-XXX ~]$ sudo touch /home/gituser/.ssh/authorized_keys [ec2-user@ip-172-31-4-XXX ~]$ sudo chown gituser. /home/gituser/.ssh [ec2-user@ip-172-31-4-XXX ~]$ sudo chown gituser. /home/gituser/.ssh/authorized_keys [ec2-user@ip-172-31-4-XXX ~]$ sudo chmod 70
BacklogのGitリポジトリからCPIサーバに自動デプロイする
Gitを使ったワークフローで、とてもとまどったのが テストアップまでの工程の長さ、スピードの遅さ です。Gitを使う前までは、作業後DWでチェックインするだけ（ポチっとするだけ）でテストアップが完了していたので「差分を抽出して手動でFTP」という段取りに「ほんとにこれでいいのかな？？と」デメリットを強く感じました。作業効率を落としてでも、コードレビューや履歴管理を取り入れるべきなんだろうか、と。 アプリやシステム開発がメインではない、いわゆるWebサイトの構築が主体の場合は、実際にブラウザで表示させた状態でのコンテンツの確認が不可欠。なので弊社でも、ローカル開発サーバとテストサーバを同期し、テストアップ後にコードのチェックを行うというフローを組むことで、テストアップまでの時間をなるべく短縮するようにしてきました。 関連記事：Git以前のワークフロー 一転Gitで管理することになると、リモー
Git 特定のフォルダのみcloneする - Qiita
リポジトリのここのフォルダだけcloneしたいんだ、Subversionでいうところのcheckoutだ、という場合はsparsecheckoutの機能を使用する。 特定のフォルダだけclone、という以外に絶対にcommitしたくないファイルを外したりできるので、覚えておくと便利(設定ファイルを個人ごとに書き換えなければならない場合など)。 git clone xxx git config core.sparsecheckout true echo I_want/this_folder/ > .git/info/sparse-checkout git read-tree -m -u HEAD echo I_forget/this_folder/ >> .git/info/sparse-checkout まずは普通にcloneをしてきて、そのあとsparsecheckoutを有効にする。
gitでシンプルなデプロイ環境を作る - Qiita
gitで最低限のデプロイ環境を作る際のメモ。 いろいろなCIツールを使うまでもない、小規模なコンパイルいらずのWebアプリのデプロイ環境を作る。 CIツールを使う場合でも基礎となる知識なので整理しておく。 やりたいこと ローカルで開発。 リモートにpush pushを拾って、公開ディレクトリにpull イメージ 図で書くとこんな感じ。 今回は、独自のリモートリポジトリを使うが、ここがGitHubとかでもいい。 前提条件 ローカル、リモートにgitがインストールされていること（Mac想定） リモート（サーバ）にはsshで透過ログインできること 手順 まずは、push,pullの流れを手動でやってみる。 リモートリポジトリの用意（リモート） とりあえず、外からは非公開かつ、チームがアクセスできるディレクトリを用意し、リモートリポジトリにする。
Stop using `git pull` for deployment! - The Grimoire
Stop using git pull for deployment!¶ The problem¶ You have a Git repository containing your project. You want to “deploy” that code when it changes. You'd rather not download the entire project from scratch for each deployment. The antipattern¶ “I know, I'll use git pull in my deployment script!” Stop doing this. Stop teaching other people to do this. It's wrong, and it will eventually lead to dep
Altax - シンプルなPHPデプロイツール
シンプルなデプロイツール AltaxはSSHを並列実行するシンプルなデプロイツールです。以下のような特徴をもちます。 PHPで書かれています。 SSHコマンドのラッパーとして実装されています。 コンパイルドパッケージを使用すれば、PHPファイル一つのみで動作します。 AltaxはCapistranoとCinamonに強くインスパイアされています。 しかし、それらではデプロイタスクをPHPで書くことができません。 Altaxは違います。以下のコードはAltaxのデプロイタスクのサンプルです。 // 出力メッセージに色を付ける set('colors', true); // 対象のホストとSSHコネクションの設定 host('web1', array('host' => '192.168.0.10', 'port' => '22'), 'web'); host('web2', array('h
シュキーンの開発とドメイン駆動設計について｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
シュキーンの開発とドメイン駆動設計について こんにちわちわ。Underbar.phpの記事ぶりになりました@emonkakです。 本エントリでは、以前のエントリでお伝えした勤怠管理アプリケーションのシュキーンの開発について述べたいと思います。 シュキーンとは シュキーンはAndroidで動作する勤怠管理アプリケーションです。打刻はNFCタグをAndroid端末にかざすことで行います。勤怠データはAndroid端末からサーバーに送信されるので、ネットワーク環境さえあればどこからでも確認することがきます。 開発のスタート 社内向けに使っていたシュキーンを一般公開に向けて改修をするということで、開発はスタートしました。メンバーは私を含む2名で進み、リリース直前に増員があり現在は3名体制になりました。今回リリースされたものは以前のバージョンからほとんど1から書き直すことになりました。 ドメイン駆動
デプロイ自動化を進めるためのチェックリスト | Ryuzee.com
いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
ぼくの考えたさいきょうの開発フロー - PHP編 - Speaker Deck
Transcript ΅͘ͷߟ͍͖͑ͨ͞ΐ͏ͷ։ൃϑϩʔ PHPฤ Yuta Adachi ࣗݾհ ҆ୡ ༐ଠ (@UAdachi) ! ग़ɿౡࠜݝদߐࢢ ͓ࣄɿChatWork ΠϯϑϥνʔϜ ! ڵຯ͋Δ͜ͱɿυϝΠϯۦಈઃܭɺScalaɺςχε (Οϯϒϧυϯ։࠵த) ! IUUQT���DJSDMFDJ�DPN ͓ॻ͖ • ։ൃϑϩʔΛ࠷దԽ͍ͯ͘͠త • ։ൃڥ • ίϛϡχέʔγϣϯ • CI • σϓϩΠ త ! • ։ൃͷߴԽ • ΦϖϨʔγϣϯϛεͷ༧ • ϓϩμΫτͷ্࣭ + ՄࢹԽ ։ൃڥ Ͳ͏ͬͯߏஙͯ͠·͔͢ʁ • Vagrantͬͯͬͯ·͔͢ʁ ϝϯςφϯε • ։ൃڥͩͬͯߋ৽͞Εଓ͚Δ • ߏஙखॱॻΛ࡞Δͷେม " εΫϦʔϯγϣοτʹҹॻ͍ͯɺઆ໌จΛఴ͑ͯ… ʮԶͷڥʯ ྫ. Aʮಈ͔Ͷʔʯ BʮԶͷڥͩͱಈ͘
第77回PHP勉強会でAltaxをとりあげていだだきました - オープンソースこねこね
4/28にEngineYardさんで行われた第77回PHP勉強会で、私がオープンソースで作っているAltaxというPHPデプロイツールをとりあげていただきました。とっても嬉しかったのでブログに書いちゃいます。PHP勉強会についての詳細はリンク先を参照ください。 第77回PHP勉強会が開催されました セッションの内容が動画でアップされてあったので先日拝見させていただきました。 登壇者の木村さんには丁寧な資料を作っていただき、デモまでして頂いて感謝の限りです。 第77回 PHP勉強会で発表してきました : ぐりぺん 自分が作っているプログラムが衆人の前で実行される場面を見るというのは、なんだか緊張と気恥ずかしさみたいなものがあって、動画を再生しているPCの前でニヤニヤ、もじもじしてしまいました。俺きめぇ。 さて、セッション内であがっていた話題などについて、いくつか言及させていただきたいと思いま
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
第77回 PHP勉強会で発表してきました : ぐりぺん
About me ゲーム好きのWebプログラマです。 使用言語はActionScriptとPHPがメイン。遊んでみたプログラムやゲームの話題について書きます。ブログのタイトルはTwitterアイコンが由来。 Twitter PHP製のデプロイツール、AltaxについてPHP勉強会で発表してきました。 この勉強会はなぜかビールの乾杯で始まるので、 発表するころにはすでに酒が回っており、 場馴れしていない緊張感も相まってきちんと説明できていたか激しく不安ですが...。 PDFファイル また、デプロイのデモで使用したコンフィグファイルもアップしておきます。 <?php // Autoloading for plugin command classes. if (is_file(__DIR__ . '/vendor/autoload.php')) require_once __DIR__
pixivの開発・デプロイ環境の変遷（2014年春版） - pixiv inside [archive]
こんにちは。最近社内で「実践F#」読書会を始めた@edvakfです。関数型言語というだけで特に理由なくF#を選んだのですが、弊社のウェブエンジニアの方々がF#にまったく興味が無いことを痛感しました。目下少数精鋭で進行中です。 さて、F#読書会とは別の曜日になりますが、pixivというアプリケーションを開発する上でのプロダクティビティを上げることを目指した「エンジニアリングプロダクティビティ向上ハッカソン」を2013年の後半から始動し、かれこれ半年近く続けています。 昨日 Immutable Infrastructure Conference #1 に参加してきたので、今日はpixivの開発環境やデプロイ環境がこの1年でどう変わったかを振り返ってみたいと思います。 2012年まで 僕が入社した2012年はちょうどsvnからgitへの移行期でした。pixivにはPC版ウェブサイトであるwww.
![pixivの開発・デプロイ環境の変遷（2014年春版） - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e06358fc6e2272b0a1032eaf66324bd3d597f17/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fd%2Fdevpixiv%2F20140325%2F20140325045217.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE
