概要 プロダクトのスタートアップでリーンに立ち上げるタイミング、マーケットフィットを経てグロースさせるタイミング、それぞれのフェーズで開発体制や運用体制、運用手法は異なってきます。 なぜそのDevOpsになったのか? DevOpsにこだわりをもつ3社をお招きして、ツール選定や意思決定の背景から、実際に活用してみた感想までをお伺いしていきます。開発をより効率的に!と考えている方、最新DevOps事例を聞きながら、一緒にディスカッションをしていきましょう! 詳細・参加申し込み TECH PLAY をご確認お願いします。 https://techplay.jp/event/687946 プログラム (1) DevOps on Merpay Microservices 株式会社メルペイ 高木 潤一郎 自社で進めているdevops on microservicesの事例を紹介します (2) ITイン
こんにちは、技術部開発基盤グループの id:hogelog です。 RubyKaigi 2018 楽しかったですね。僕はおそらく RubyKaigi 2010 以来の久しぶりの参加でした。ああいう場の楽しさを思い出し、また今回はスポンサーブースから RubyKaigi に参加するという学生の頃は知らなかった楽しみも新たに知り、RubyKaigi を満喫させていただきました。 さて今回はそんな RubyKaigi で取り戻した Ruby に対する感情と関係あるようなないような、最近自分が取り組んでいるお台場プロジェクトとプロジェクト内で実施している計測と可視化について紹介します。 お台場プロジェクトの発足 クックパッドの開発といえば数年前までは cookpad_all という一つのリポジトリの中に詰め込まれた巨大なモノリシック Rails アプリケーションを社内のエンジニアが寄ってたかって開
多くのバグが発見されて、いつまでたっても結合テストが収束しない―。筆者は過去、何度かこういう状況に遭遇した。この状況で多発するバグはたいていの場合、設計工程ではなくプログラミング工程(以下、実装工程)に起因するものだった。 実装工程中のコード品質チェックは「ソースコードレビュー」「単体テスト」「単体テストケースおよび結果のレビュー」といった流れで進める。これらを徹底できれば品質が向上するものの、種々の理由から「徹底は難しい」という現場をよく見る。大きな理由の一つが、レビューアーの負担が大きいことだ。レビュー作業は経験やスキルに依存するため、高スキルの技術者が必要になる。大規模開発では高スキル技術者を多く確保する必要が出てくるが、現実には厳しい。 問題解決手段の一つが「実装工程中のコード品質を可視化してWeb上で共有できる仕組み」の導入だ。筆者のチームではこれを「コード品質共有システム」と呼
はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計/実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア
Blogs DevSecOps and DevNetOps: New Heroes in the DevOps Saga The evolution of DevOps is by no means done, but it’s safe to say that there is enough agreement and acceptance to declare it a hero. DevOps has helped glorify IT to the point where it’s no longer preventing business, nor a provider nor a partner of the business. Often IT is the business, or its vanguard for competitive disruption and di
読者のみなさんに簡単な問題を出したい。「トラブルが半年に一度発生するシステムと、5年に一度しか発生しないシステムでは、どちらが深刻な事態になるか」。まずは最近発生した事件について見たうえで、答えについて検討してみたい。 2017年8月29日、北朝鮮がミサイルを発射した際、Jアラート(全国瞬時警報システム)は警報を発したものの、各地で情報伝達がうまくいかないトラブルが「また」発生した。 総務省消防庁によると警報の対象は12道県617市町村だが、24市町村において情報伝達に支障が生じたという。理由は様々だが、「Jアラート関連機器の設定誤り」が5件、「登録制メール配信システム関連機器の設定誤り」が8件など、人為的ミスをうかがわせる要因が大多数を占めた。 「また」と書いたのは、Jアラートはこれまで何度も、動作不良や誤報を繰り返してきたからだ。2016年11月にも、茨城県の自治体で震度5弱の地震が発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く