👺 Hubot で Slack から AWS ECS にデプロイ
🏭 Docker を Production 投入するメリットを考える 仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導... portalshit.net Kaizen Platform 時代は Naoya Ito さんの以下の記事にあるような感じで deploy してた。 Slack 上で hubot に話しかけると deploy 用の Pull Request が作られていい感じに deploy フローが始まる。 GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー 少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそ
🏭 Docker を Production 投入するメリットを考える
仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導入した。自動テスト、コンテナイメージのビルド、デプロイには CircleCI を利用している。 .circleci/config.yml は以下のような感じ。 version: 2 shared: &shared working_directory: ~/app docker: - image: xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app environment: PGHOST: 127.0.0.1 PGUSER: user RAILS_ENV: test REDIS_HOST: localhost - ima
一休.com におけるフロントエンド開発 // Speaker Deck
3.29 Sansan✕一休.com 勉強会での発表資料です
外資就活ドットコムの開発ワークフローの再設計 - ハウテレビジョンブログ
はじめに さまよえるアラフォー男子 @artifactsauce です。 突然ですが、弊社は「外資就活ドットコム」というWebサービスを開発・運営している会社です。サービスイン当初はイケイケガンガンで高速開発・高速リリースをうたっていましたが、開発者が増えるにしたがって様々な問題が発生してきました。今回はプロダクトのリリースにまつわる問題を解決するために弊社で採用した開発ワークフローについて紹介します。 どんな問題が起こっていたのか？ Capistranoによる自動デプロイは実現していた我々ですが、それですべてがうまくいったわけではありませんでした。具体的には以下の様な問題が発生していました。 デプロイできる環境を用意するのが面倒である。 各デプロイ担当者がデプロイツールをインストールする必要がある。 デプロイツールを更新していない場合には失敗する。 デプロイ対象サーバーにデプロイ担当者の
ファイル更新もchef実行もstretcherで！Lobiをデプロイするときにやっていること - KAYAC engineers' blog
Lobiチームの長田です。 今回は現在運用中のLobiというサービスのデプロイについて紹介します。 Lobi Chat & Game Community Lobiについての紹介は以前のエントリを参照ください。 サーバーサイドエンジニア視点でLobiというサービスを紹介します | tech.kayac.com - KAYAC engineers' blog TL;DR デプロイ=各種ファイル更新とサービスへの反映、chefの実行 毎日十数回のデプロイを行っている デプロイ対象は数十台単位 十余名のサーバーサイドエンジニア全員にデプロイ権限がある Auto Scalingを考慮したデプロイ手段を採用している ファイル更新もchef実行もstretcherでOK まだまだ改善の余地あり おおまかな手順 本番環境にデプロイするぞ！という段になると、こんな操作が行われます。 GitHub上でコードレ
9分43秒のデプロイを19秒にした話 - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
背景 アカツキではRailsでゲームサーバを開発しています。インフラはAWSにあり、CloudFormation, Chef, Capistrano を用いて、Infrastructure as Code を実現しています。 エンジニアは普段ローカルマシンで開発していますが、ディレクター、レベルデザイナーなどは定義ファイルを変えた後、それを反映して動作を確認するための検証サーバ（以下、検証環境）を使っています。 検証環境へのデプロイも Capistrano で自動化しており、最初は問題が無かったのですが、ゲーム上のデータが増えることによって、一度のデプロイで10分程度かかるようになっていました。 以下、Capistrano ver.2系の話にはなりますが、検証環境のデプロイを高速化したので、その内容を紹介したいと思います。 現状分析 rsync について、capistrano_rsync_
wordmove – WordPressサイトを一発デプロイ
WordPressをベースにWebサイトを構築する場合、 – ローカルにPHPやApacheを用意して開発用サーバを立ち上げ – ローカルで動作を確認しながら開発 – リリース時に本番環境にアップロード という流れで開発する場合が多いのではないでしょうか。 このとき問題になるのが、ローカル環境で行ったデータベースの変更をどうやって本番環境のデータベースに反映させるか、ということです。基本的には mysqldump でダンプしたSQLファイルを本番環境のMySQLに食わせればいいのですが、ローカル環境のデータベースには http://localhost/foo/bar というように、ローカルホストのホスト名が入り込んでいる場合があります。さらに、一部の文字列は文字列長と文字列の組でシリアライズされているため、単純にホスト名を置き換えるだけでは不十分です。このようなデータベースの変換を自動で行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SSSSLIDE