はじめに この記事はJaSST'18 Tokyo（ソフトウェアテストシンポジウム）のパネルセッションを書いたものです。 JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo 自己紹介 バックグラウンドが違い、コンテキストが違うことがある そこで自己紹介時に、どれくらいの頻度でDeployしているのか、どれくらいの頻度でリリースしているのかを踏まえて話してほしい。 荻野 恒太郎（以下、荻野） 楽天 テスト自動化とDevOpsのマネージャをしている。 デプロイは毎日数十回実施 1週間に数回リリースしている 天野 祐介（以下、天野） サイボウズ kintoneの開発チームに所属 エンジニアが10数名、QAなどを含めると30名ぐらいのチーム 2015年にチームリーダーになった 今はスクラムマスター中心 最近、WaterFallからAgile開発に変更していっている 今は1イテレー
SREの@deeeet です。 MercariではSlack Botを使い様々な業務の自動化を行っています。例えばメインのAPIのReleaseはBotによる自動化がされており、JPとUSとUKの3拠点で1日に10回以上のReleaseをSlack上で実現しています（これ以外にも多くの事例があります）。 これまでのSlack Botは基本的には文字ベースでのやり取りが普通でした（グラフなどの画像を返答として利用することはあります）が、SlackはよりInteractiveなやりとりを実現できるInteractive Messageという仕組みも提供しています。これによりButtonによる決定やMenuによる選択といったアクションをユーザにとらせることができるようになります。 Buttonの仕組み自体は古くから提供されていましたが他のTeamへの配布が前提でありOAuthの仕組みを準備する必
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
Feature Toggles Pete HodgsonさんというThoughtWorksの方が書かれたFeature Togglesという記事が面白かったので翻訳してみました。 「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016の記事で取り上げていただいた通り、マイクロソフトの内部の開発では多くのフィーチャートグルが使われています。このことをより深く理解したいと思って個人的に翻訳したものを公開します。私的な自分が理解する用の翻訳でありますので、その辺はご考慮いただければと思います。Pull Requestは歓迎いたします！ 概要 フィーチャートグルズ(Feature Toggles)は、とてもパワフルなテクニックだ。チームがコードを変更することな
Amazon のオススメ本に出てきた「 サッカー データ革命 ロングボールは時代遅れか 」を読んでみました。 この本は、野球界における「 マネーボール 」のように、 サッカーを様々なデータを元に見つめ直すような内容になっていて、 例えば、チームが負けているときに交代によって最大の効果を得るためには、 1 人目の交代を後半 13 分、2 人目を後半 28 分、3 人目を後半 34 分までに行うべきとか、 極端に能力の高い選手を獲得するのと弱点となる選手の穴を埋める補強はどちらがいいのかとか、 統計を元にしたサッカーに関する興味深い考察が多かったのですが、その中に 1 つ引っかかる話があったのでそれについて書いてみます。 良いディフェンダーはタックルをしない 本書の中で、 四半世紀に渡ってマンチェスター・ユナイテッドを率いた名将ファーガソンが、 オランダ代表のディフェンダー、ヤープ・スタムを放
こんにちは！kintone 開発チームの田中裕一(@yuichielectric)です。 O'Reilly Mediaがサンタクララで開催したVelocity Conference 2015に僕と佐藤鉄平(@teppeis)の2人で参加してきました。これから何回かに分けてそれぞれが面白いと思ったセッションの内容を紹介していこうと思います！ Velocity Conferenceとは O'Reilly Mediaが主催しているカンファレンスで、高速でスケーラブルで価値のあるサービスを作るための方法論がテーマです。 もともとは、技術的なテーマが主だったようですが、最近はそういったサービスを開発するために必要となってくる、継続的インテグレーションや継続的デリバリーの手法や、アーキテクチャ（流行りのmicroservicesの話題も幾つかありました）、開発プロセス、組織論（DevOps絡みの話題が
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
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
「マイクロサービス」という新しいアーキテクチャスタイルが話題になっています。ごく簡単に言えば、1つのシステムを複数の小さなサービスを組み合わせて実現することです。マーチン・ファウラー氏とJames Lewis氏が今年の5月に公開した記事「Microservices」で注目が集まりはじめました。 参考："Microservices"を読んだ | SOTA 参考：クックパッドとマイクロサービス - クックパッド開発者ブログ 参考：マイクロサービスとSOA - InfoQ このマイクロサービスを実現する上で、組織が備えていなければならない能力について、マーチン・ファウラー氏が先月、「MicroservicePrerequisites（マイクロサービスの前提条件）」という記事を公開しています。同氏のWebサイトの記事は翻訳が許可されているので、ここで翻訳を紹介したいと思います。 マイクロサービスの
退職時の引継ぎの際に、chefで自動化されている作業を(chefを使わなくて済むように)サーバ構築手順書としてドキュメント化してくれと言われた…
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
本日、Mackerelをベータ公開しました。 Mackerelは、ウェブアプリケーションのパフォーマンスとインフラを管理するための新しいサービスです。 Mackerelとは Mackerelは、次のような問題を解決することを目指しています。 複数のサーバのリソース状況を効率的に可視化 各種ツールと連携することでサーバ情報の多重管理を解消 複数のクラウド環境を一元管理 リソース消費状況を可視化するだけではなく、APIによる各種ツールとの連携で、開発と運用の自動化をより促進させていきます。 詳細は、下記のリンクからどうぞ。 利用開始 https://mackerel.io/ja/ ヘルプページ https://mackerel.io/ja/docs/ 正式化に向けて ベータ期間中は、すべての機能を無料でご利用いただけます。正式版では無料でご利用いただける範囲に制限がつきます（料金などの詳細は正
少し前までアプリケーションのデプロイと言えば 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 と連携するこ
なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り： これは自分の部署で初めて 本番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正（例：SQL文の変更）などを自分以外の人間が施した後にサーバーを簡単に再コンパイル＋再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log
AWS Elastic BeanstalkがDockerをサポート、新しい形態のPaaSへ。事実上どんな言語でも使え、手元の開発環境をそのままPaaSへデプロイできる コンテナ型仮想化を実現する技術「Docker」が、PaaSの新しい形態を生み出そうとしています。 いわゆる従来のPaaS（Platform as a Service）は、使えるプログラミング言語がPaaSによって決められています。例えばHerokuならRubyやPython、Node.js、Javaなど（記事末追記参照）、Google App EngineならPythonやGo、Java、PHPなどです。 しかし、あらかじめPaaS側に実行環境があることで開発者は手軽にプログラムをクラウドで実行でき、クラウドが負荷などに応じてスケーラブルな運用をしてくれます。ここにPaaSの大きなメリットがあります。 一方でPaaS側の実行
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
