You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
上：左からWerckerのCTOのAndy Smith氏、CEOのMicha Hernández van Leuffen氏、CCOのWayne Gibbins氏 Image Credit: Gray Powell/Wercker コードのテスト及びデプロイプロセスを自動化するツールのスタートアップであるWerckerは本日、450万米ドルの資金調達ラウンドを発表した（編集部注：原文掲載1月28日）。同社はまた、GitHubのオープンソース使用許可のもと、コマンドラインインターフェース（CLI）のリリースも合わせて発表した。 「新たに調達した資金により、Werckerは大企業向けの機能を備えた製品をさらに増産することができます」と、同社設立者兼CEOのMicha Hernandez van Leuffen氏はVentureBeatのインタビューで答えた。 競合にはCodeship、Circl
こんにちは寺岡です。 この記事は TECHSCORE Advent Calendar 2014 の 3 日目の記事です。 それは遥か昔、世界が未だデプロイツールを手に入れる前のお話。 その頃のエンジニアにとって、デプロイは神聖かつ盛大な儀式であった。 儀式には決して破ってはいけない戒律が存在した。 「tar、scp、rakeなどの高度で難解な呪文を駆使し、正しい順序をもって執り行うべし」 戒律は地域、文化、宗教の違いによりさまざまなバリエーションが存在し、儀式の困難さに拍車をかける。 しかし、最後は必ずこう締めくくられるのだ。 「一度呪文を間違えたその時は、大いなる災厄がこの世を襲うであろう」と。 災厄を恐れたエンジニアたちは、長大で重厚な手順書を作り、なんとかデプロイを乗り切ろうとした。 それでもなお、手順書のバグやタイプミスにより悲劇は繰り返されるのであった…。 しかし、度重なる悲劇と
SA岩永です。クラウド時代になり、Blue/Greenデプロイと呼ばれる方式を取るシステムが増えてきました。ただ、日本語で書かれているBlue/Greenデプロイの情報は多少古いものが多いため、特にクラウドで真価を発揮するBlue/Greenデプロイについて2015年の最後に一度まとめてみたいと思います。 以下は私の個人的な考えに基づくものであり、他にも様々な考え方があります。AWSのデプロイに関する発表でも沢山の考え方が提案されていますし、デプロイをサポートするサービスを多種多様に提供しています。1つの考え方として参考にして頂ければ幸いです。 なおこの記事は、2015年のAWS re:Inventのセッション『(DVO401) Deep Dive into Blue/Green Deployments on AWS』を参考にしています。興味のある方はSlideshareやYoutubeを
このブログをご覧のみなさま初めまして。@siroken3です。メルカリではインフラチームに所属しており、リリースの仕組み構築を担当しています。 メルカリのリリースについて メルカリではカスタマーサポートから受け取る改善要望、プロダクトとしてまだやれてないことなど多くのタスクがあり現在も継続して開発とリリースが行われています。 Issue管理はRedmine、ソースコードのリポジトリはGitHub privateを使用しています。Pull Request(以下PR)でのコードレビューを実施、masterブランチへマージされたものをリリースするのが基本的なフローです。 一方、1年前まではリリース頻度は週1回のリリース日を決めて実施していましたが、この1年で大きく変わりました。現在では日本版とUS版を合わせて10回〜30回/日の頻度でリリースしています。この記事では大きく変わったメルカリのリリー
Top Announcements of the AWS Summit in New York, 2023 It’s probably no surprise that generative artificial intelligence and machine learning were the stars of the show, but there were several other bright lights from the day-long cloud conference. New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i) Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex
こんにちは。西山です。 毎日続く炎天と夕方に来襲する豪雨で夏らしさが一気に全開になりましたね。 今回はデプロイツール「Rocketeer」についてご紹介したいと思います。 これは GitHub上で公開されているオープンソースソフトウェア (OSS) です。リポジトリは https://github.com/Anahkiasen/rocketeer にあります。ライセンスは MIT です。 デプロイツールというと、以前の現場で Capistrano を使っていたのですが、これは Ruby 製ですね。 Rocketeer は Capistrano に似た構成を持つ PHP 製のソフトウェアです。普段、PHP の案件に関わることが多いのですが、デプロイツールも同じ PHP で書かれていたほうが安心感（？）がありますよね。 また、Composer や PHPUnit の実行にもデフォルトで対応
Daniel Schauenberg氏は先日のQCon Londonで、DevOpsや継続的インテグレーションを実践していることで有名なEtsyが、いかにして1日に50回ものデプロイをしているのかについて語った。リスクを最小限に抑えながらこのペースの変更を実現するためには、完全に自動化されたデプロイメントパイプライン、徹底的なアプリケーションのモニタリング、IRCベースの共同作業、これらすべてが重要なのだ。 Etsyの開発への取り組みは、いくつもの小さくて途切れることのない変更を中心に回っている。直接影響するのは、一日に何度もデプロイする必要性だ。Daniel Schauenberg氏の言葉を借りれば、Etsyの開発者はいつどんなときでも「今すぐこの変更をデプロイするゆとりが自分にはあるか？」という質問の答えを知っていなければいけない。常にゆとりを持てるように、Etsyはさまざまなツールや
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
by @dekokun on 2013/05/21 23:46 Tagged as: Capistrano, Fabric. 最近、Fabric, Capistranoと立て続けに2種類のデプロイツールを使ってデプロイ環境を構築する機会がありましたので、その際に感じた両者の利点を書いてみたいと思います。 両者の簡単な解説 そもそもCapistrano, Fabricについて、「片方は知っているけど片方は知らないよ」という人がいるかと思いますので、簡単な説明をします。 両方とも何かを知らない人は…「自動デプロイ」とかそのあたりで検索してみるといいんじゃないですかね。 Capistranoとは Ruby製のFabricみたいなものです Fabricとは Python製のCapistranoみたいなものです Fabricは私の中ではデプロイツールという認識なのですが、最近Chefと比較されること
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
GitHub / Bitbucket のプライベートリポジトリも無料で CI し放題の wercker というサービスがあります。(2013/11/30 現在) サイトもきれいで素敵です。ビルド成功後、Capistrano でデプロイが自動実行される方法を書いておきます。 まず、アプリの設定で SSH 公開鍵を作成します。 生成された公開鍵は、デプロイ先サーバの ~/.ssh/authorized_keys や Bitbucket のデプロイ鍵などに追加しておきます。 次に、アプリの設定から Deploy targets の設定をします。Custom deploy を選択して、 master ブランチのビルドに成功したら、自動デプロイするようにします。 入力したら、Deploy pipeline の Add new variable をクリック。 SSH Key pair を選択し、先ほど
Capistrano、便利ですよね。 capistrano/capistrano 最近メジャーバージョンアップがあったのですが、使い方、というかスクリプトの書き方やお作法が変わり、「Capistrano 3にアップデートしたはいいけど全然動かなくてどうなってんだ」という流れはもはやお約束みたいです。 試しに僕も個人で作ってるウェブサイトのCapistranoをアップデートしてみたので、その上でこんなところに気を付けたいな、と思うポイントでも書いておきます。 capifyは使わない Capistranoを使うときは$ bundle installをし、次に$ bundle exec capify .とするのがお約束の流れですが、これからはcapifyを使ってもcap installを使ってねと言われます。 ですので: $ bundle exec cap installとしましょう。 マルチス
Capistrano deployment tips collection document summarized in 3 sentences: The document shares tips for using the Capistrano automation tool, including recommendations for colorizing Capistrano commands with the capistrano_colors plugin. It also describes using the capistrano-ext plugin to better organize different deployment configurations and set environment-specific options. The document provide
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
Capistranoはデプロイツールだ。簡単な設定さえしておけば、後はコマンド一つでリモートサーバでソースを展開し、データベースのマイグレーションをはじめ必要な処理を行ってWebサーバの再起動をしてくれる。毎度行うと手間のかかるデプロイ作業が簡単に終わるのだ。 PHP用のリモートデプロイツール CapistranoはRailsアプリケーションで使うともとても便利だが、それをPHPのフレームワークSymfonyでも使えるようにしたのがCapifonyだ。 今回紹介するオープンソース・ソフトウェアはCapifony、PHP用デプロイツールだ。 PHPはRailsのようにWebアプリケーションサーバを用意する必要がないので（今はPassengerがあるが）、そんなものは不要と思うだろうか。だがPHPのコードをリモートサーバ側でバージョン管理システムから取り出し、データベースの設定を変更し、Web
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
