【翻訳記事】デプロイ戦略の定義 - そこに仁義はあるのか(仮)
この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ
継続的デプロイ＆ダウンタイムなしのデプロイのために - Qiita
みなさん、デプロイしてますか！！ ロールバック失敗してないですか！！ ロールバックが失敗したとき冷や汗かきますよね。 さて、何気なくしているサーバーに対する新バージョンのアプリデプロイ。 どんな方法があるのでしょうか。 簡単にですが利用したことがある方法をまとめてみました。 サービス停止＆デプロイ 最もシンプルですが駄目な奴です。 サービスを停止させないとデプロイできない悲しい方法。 アプリに必要なファイルを上書きしていたり配置している瞬間はサーバーが動作しないためです。 シンボリックリンク・デプロイ CapistranoやFabricが有名かと思いますが、各サーバーに新しいアプリを配置してから一気にシンボリックリンクを書き換えていき、新しいアプリに向けさせる方法です。 ロールバックする場合は以前のシンボリックリンクに戻します。 たまにロールバックに失敗して悲しいことになることも。 Rai
3倍どころか10倍速い！ Jenkins のビルドを高速化して、シャアを超えた男 | 株式会社ヌーラボ(Nulab inc.)
実はガンダムを見たことがないので、時々社内のガンダムトークについていけないことがあります、中村です。今日は、 Jenkins のビルドを高速化し、リリースまでの時間を大幅に短縮した、改善策をご紹介します。全体で2~3倍程度、一部処理では何と10倍以上もビルドを高速化できました。 改善策1 : push 型デプロイから pull 型デプロイへ 改善策2 : テストケースを自動分割して、よりアグレッシブに並列実行 全体のリリース時間に対する改善結果 ビルド時間の可視化 改善策1 : push 型デプロイから pull 型デプロイへ まずはデプロイ時の方式を、push型デプロイからpull型デプロイに変更した改善策を説明します。ここで、push型デプロイは中央サーバからデプロイ用ファイルを転送する方式で、pull 型デプロイは各サーバがファイルを取得する方式とします。 各フェーズの構成は、下図の
Travis CI 入門：GitHub + Travis CI で継続的インテグレーション « をぶろぐ
1. Travis CI とはTravis CI はオープンソースコミュニティのためにホストされた CI（継続的インテグレーション）サービスです。 継続的インテグレーションってなんだ？ 継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。エクストリーム・プログラミング (XP) のプラクティスの一つで、狭義にはビルドやテスト、インスペクションなどを継続的に実行していくことを意味する。特に、近年の開発においては、継続的インテグレーションをサポートするソフトウェアを使用することがある。 引用: 継続的インテグレーション - Wikipedia Travis CI は GitHub と連携しており、CI したいリポジトリーを接続しておくと、Travis CI がコミットを
The best CI/CD tool for high-performance engineering teams - Semaphore
The best CI/CD solution for high-performance engineering teams.
Semaphore(CI/CD)をセットアップしてみた | DevelopersIO
Semaphore SmaphoreはクラウドのCI/CDツールです。 ざっくりいってしまえばTravis CIやCircleCIのようなツールとなります。 The world’s fastest CI/CD platform Continuous Integration & Delivery with Docker Support - Semaphore とのことで、速度を売りの一つにしているようです。 公式サイトにはCodeship,Travis CI,CircleCIでテストスイートを実行した際の速度比較が記載されています。 GitのホスティングサービスとしてGitHubとBitbucketが選択できるようです。今回はGitHubのプロジェクトと連携してみます。 やってみた GitHubのアカウントをそのまま利用できるので、こちらのGet Started with GitHubからサ
失敗する前提でデプロイする - hitode909の日記
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
SpinnakerによるContinuous Delivery | メルカリエンジニアリング
SREの@deeeetです。 新しい機能を素早くリリースしフィードバックを得てすぐにPivotの決定を行う、もしくはリスクを抑え小さな改善を継続的に行うContinuous Deliveryはソフトウェア開発において非常に重要です。 メルカリではこのContinuous DeliveryのためのPlatformにSpinnakerを採用し始めました。現在は主にkubernetes（k8s）へのコンテナアプリケーションのDeployに利用しており、既にいくつかの本番アプリケーションがSpinnakerによりDeployされています。 本記事ではなぜSpinnakerを採用したか、Spinnakerとは何か、実際にメルカリでどのようにSpinnakerを使っているか、について簡単な紹介をします。 kubernetes上でのDeploy問題 k8sへのコンテナイメージのDeployは非常に簡単で
入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineering
はじめに この記事はGREE Advent Calendar 2013年の21日目です。お楽しみください！ こんにちは、アゴひげがダンディーだと評判の九岡です。GREEでは、JavaやScalaを布教するための土台を固めるため、デプロイや監視の仕組みづくりなどを横断的にやっています。今回はその過程で得られた知識を「Capistrano 3の入門記事」という形で共有させていただきます。 この記事ではCapistrano 3の基礎をご紹介します。Capistrano 3はRubyをベースにしたサーバ操作およびデプロイの自動化ツールです。Capistrano 3を利用することで、デプロイなどの複雑なサーバ操作を自動化することができます。ここの記事では、特にデプロイに焦点をあてながら、Capistranoでサーバ操作を自動化する考え方と実現方法をご説明していきます。 Capistrano 3の習得
開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー
開発メモ#1 : Cinnamon によるデプロイ - naoyaのはてなダイアリー に引き続き、その2です。 最近は個人で作るような小規模なものでも AWS を利用してホストしています。たとえ個人で作ったものとはいえ、利用するユーザーがいる以上はおいそれと落とすこともできない。かといって運用にあまり手間をかけたくない。その辺り、AWS で解決できる点が多い。 AWS の良いところはインフラが動的なので「後からどうとでもなる」ところ。 インスタンスの性能が足りないのであればスケールアップするでもいいし、冗長性が欲しくなったらそのタイミングで ELB (ロードバランサ) を用意すれば良い。その時、仮想化されていないハードウェアを使っていると移行のためにサーバーを再セットアップしたりアプリケーションをデプロイし直したりと手間がかかるところ、AWS ではその辺りの手間がほとんどかからない･･･と
DeployGateについて - ほげほげ（仮）
Android Advent Calendar 2012 (裏) 12/23担当の@STAR_ZEROです。 表は@shogoggさんです。 DeployGate使っててすごく便利だと感じたので軽く紹介します。 前日のネタとカブり気味ですが… 詳しい使い方等は公式ドキュメントも合わせて参照してください。 DeployGateは管理ツールにAPKファイルをアップロードすることでテスト端末に一斉に配信することができます。 これにより様々な動作確認・テストを手間なく開始することができます。 アップロードするアカウントは有料。テスト用アカウントは無料です。 DeployGate使用時のフロー DeployGateを使うことでAPKを渡す手間がかなり軽減できます。 あとで軽く触れてますがJenkinsを使うとさらに手間がなくなり、素早いフィードバックを得られます。 DeployGateを使用するため
シンプルなデプロイツールを書いているという話 - Kentaro Kuribayashi's blog
デプロイツールにcapistranoを使っているのですが、経年劣化により、何をやっているのか意味不明になり、機能追加しようにもどうにもならない感じになってきたので、もっとシンプルなものを作ってみようというわけで、ちょっとやってみています。 https://github.com/kentaro/cinnamon 設計指針は以下の通り。 role/taskという枠組みはcapistranoと同じ というか、このモジュールは、role/taskの管理 + アルファだけを提供する 設定のset/get コマンド実行(run/sudo) リモートでのコマンド実行(remote) (いまはないけどstreamみたいなのも欲しい) 普通、デプロイツールというのは、デプロイ先のディレクトリ構成をいい感じにしてくれたり、VCSとの連携を上手いことやってくれたりするわけですが、このモジュールはそういうことはし
Fabricインストールメモ - wyukawa's diary
Hadoopのような複数台のマシンを相手にする作業だと一括でコマンド発行したいことがあります。 その際に各マシンにいちいちSSHでログインして作業するのは面倒です。 なのでその辺りを解決するツールが欲しくなります。 Hadoop徹底入門だとparallel-sshが紹介されています。 ただこれだとsudoがうまくいかないんですよね。 sudo: sorry, you must have a tty to run sudoと言われます。 Google Code Archive - Long-term storage for Google Code Project Hosting.によれば-xオプションつけてsshの-tオプションを渡せば良いように見えますが、 pssh -h hostlist -O "StrictHostKeyChecking=no" -x -t -A -l ユーザ -i "
Fabricを使ってリモートサーバーでコマンドを実行する - スコトプリゴニエフスク通信
Python版のCapistranoと言われて久しいFabricだけど、ドキュメント通りにやっても全く動かなかった経験があるのでずっとスルーしてきた。http://pypi.python.org/pypi/Fabric/0.9rc1http://docs.fabfile.org/0.9/PyPIに上がっている0.9というバージョンは、まずまず動くので検討する価値がある。インストールはいつも通り、 $ pip install Fabric 基本的なことFabricをインストールするとfabというスクリプトがインストールされるので、 $ fab -H localhost -f fabfile.py command> のようにして実行する。fabfile.pyは設定ファイルの名前だが、fabfile.pyという名前で設定ファイルを保存しておけば省略できる。-Hオプションはホスト名の指定。オプショ
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。
Fabric で rsync する - Memo
Python のデプロイツールである Fabric を普段から使っている。 で、Fabric で rsync をする場合は以下のように書く。 #!/usr/bin/env python # -*- coding: utf-8 -*- import os from fabric.api import env, run, roles, cd from fabric.contrib import project, console env.user = 'username' env.roledefs = { 'web': ['192.168.1.10', '192.168.1.11', '192.168.1.12'] } @roles('web') def rsync(): project_path = '/path/to/projects' dirname = os.path.dirname l
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkinsを使ったコンシューマゲームでのデプロイとテスト
https://jasst.jp/symposium/jasst16tokyo/pdf/E2.pdf
Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~
Fabric — Fabric 1.3.4 documentation