Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.
Creates a "release pull request", whose body consists of features list or pull requests that are to be released into production. It's especially useful for QA and pre-release checks. git-pr-release automatically collect pull requests merged into master branch and generates the content of the release pull request. Suitable for branching strategy like below (similar to git-flow): Feature branches ar
こんにちは、@ttskchです。先日、Symfony Meetup #5のLTでChatOpsについて発表させていただきました。 発表に使用したスライドはこちらにあります。 具体的には、PHP(特にSymfony2)プロジェクトの開発・リリースのプロセスについてのお話しです。 ここでは、その発表の内容をもう少し詳しく解説したいと思います。大きく5つのステップに分けて、一つずつ解説していきます。少し長いですがお付き合いください。 Step 1. CIの導入 Step 2. Capistranoの導入 Step 3. デプロイの自動化 Step 4. リリースPR作成のQA最適化 Step 5. リリースPR作成のChatOps化 Step 1. CIの導入 まず一番初めにやるべきはCIの導入です。弊社ではCIサービスにCircleCIを使っています。 CircleCIとGitHubを連携させ
クックパッドにおけるアプリのデプロイの資料が非常に興味深いので紹介します.これは @sora_hさんがRubyKaigi 2014で発表 された資料で,100台以上のサーバに短時間でアプリをデプロイする仕組みをどうやって作り上げたのかが説明されています. 以前,スライドの内容を箇条書きにまとめていたのでシェアします.最近では,Jenkins User Coferenceの発表(How We Use Jenkins? // Speaker Deck)でほんの少し引用されていたりします. 内容のまとめ スライドは90枚あります.ざっくりまとめた内容を以下に示します. 概況 140サーバに1日10回のデプロイを実施している(ピーク時) コードベースが大きい モデルだけで約 69K LOC プロダクトコードとテストコードを合わせると約 319K LOC デプロイのルール CIのビルドが成功したリビ
capistrano2系で使っていた-s/-Sオプションが使えなくなっていた。 検索すればいくらでも見つかる話ではあるが気にせずメモ。 タスクにパラメータを渡す方法として、実行時に環境変数で渡す方法と、実行中に対話的に渡す方法があるみたい。 環境変数でパラメータを渡す そのままずばり、ENV['NAME']で取ってくる deploy.rbや deploy/[env].rbに以下のように書く
少し前までアプリケーションのデプロイと言えば 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 と連携するこ
背景 アカツキではRailsでゲームサーバを開発しています。インフラはAWSにあり、CloudFormation, Chef, Capistrano を用いて、Infrastructure as Code を実現しています。 エンジニアは普段ローカルマシンで開発していますが、ディレクター、レベルデザイナーなどは定義ファイルを変えた後、それを反映して動作を確認するための検証サーバ(以下、検証環境)を使っています。 検証環境へのデプロイも Capistrano で自動化しており、最初は問題が無かったのですが、ゲーム上のデータが増えることによって、一度のデプロイで10分程度かかるようになっていました。 以下、Capistrano ver.2系の話にはなりますが、検証環境のデプロイを高速化したので、その内容を紹介したいと思います。 現状分析 rsync について、capistrano_rsync_
最近開発で利用している、デプロイをチャット経由で行うフローについて説明します。 要点 開発者はmasterブランチで開発する 開発者はデプロイしたいときにBotにお願いする Botはmasterブランチからproductionブランチに対してPull Requestをつくる 開発者はPull Requestを確認してmergeする CIはproductionブランチが変更されるとサーバにデプロイする ChatOps masterブランチからproductionブランチにPull Requestを出す作業は面倒なので、チャット経由で行っています。Heroku上で動かしたRubotyにruboty-githubとruboty-aliasというプラグインを入れて、「デプロイしたい」と発言するとPull Requestを作成するように設定しています。チャット経由で物事を行うようにすると、周知や教育
この当時の内容と大きく変わっていませんが、最新のRails開発について公式テックブログに書きました。そちらも合わせてご参照ください。 この記事はGunosy Advent Calendar 2014の22日目の記事です。 こんにちは、Gunosyのtoshimaruです。Gunosyでは主にRuby on Railsアプリを担当しています。 はじめにGunosyでは昨年度よりAPIの実装をRails実装からGo実装へと変えたことでAPIのパフォーマンスの大幅な改善が行われました。そんなわけで「GunosyってRails捨ててGoを使ってるんじゃないの?」とお思いの方もいらっしゃるかもしれませんがそんなことはありません。大規模アクセスのない管理画面などではRuby on RailsはまだまだGunosyで現役バリバリです1。高速にWEBアプリを作る必要のあるシーンにおいてはGoはRailsに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く