本番環境でテストするって話の日本人の反応と海外の反応
https://x.com/HighWiz/status/1817197569099051158 マリーアントワネット「検証機がないなら，本番環境を使えばいいじゃない。」 これに対し，日本のITエンジニアたちは激おこである。 そして大半が本番環境でテストをするのはけからんという話に終始している。これが日本の姿である。 まるでオライリーの「オブザーバビリティエンジニアリング」で書かれていた本番環境をガラスの城として扱っているパターンそのものって感じがある。 https://netflixtechblog.com/tagged/chaos-engineering 一方，Netflixのようなグローバル大企業はすべからく本番環境でテストを行っている。 彼らは惑星規模の計算資源とその上で稼働する大規模なマイクロサービスを運用しているので，事実上，本番環境と同等の検証環境を作ることができない。 さら
Postman 入門
今回の記事は、2023年8月29日に開催されるPostman Meetup Fukuokaの登壇に向けて、Postmanへの感謝を伝えるために執筆した記事である。 今回の記事は、これからPostmanを実務で導入するプログラマーを対象に基本的な使い方を解説した記事になる。Postmanの専門的な使い方を知りたいならPostman Learning Centerを確認してほしい。本記事はあくまで二次情報に過ぎないので、より正確な情報を求めるならそちらを参照すること。 今回の記事では、API設計・開発で重宝するサービス「Postman」の使い方を解説する。 対象者 これからPostmanを学ぶひと 実務でPostmanを触っているひと Postmanに興味があるひと タイトルでなんとなく気になったひと Postmanとは PostmanはWeb API(以下「API」)の設計・開発、テストをサ
【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
この記事は？ それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W
リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
テストコード導入奮闘記～私はこうやってプロジェクトにテストコードを導入しました～ - Qiita
導入 どうやら新卒2年目社員のAさんが上司のZさんにプロジェクトにおいてテストコード導入を打診してるようです。少し内容を見てみましょうか。 Aさん(新卒2年目社員)「最近テスト自動化やテストコード、TDDなどの単語をよく聞きます。うちはテストコード書いてないですし、実装後の簡単な動作確認、最終の結合テストしかしていません。開発体験と品質を上げるために、テストコードを導入したいです。」 Zさん(上司)「そうは言うがね、君。今のうちの状況を見てごらんよ。みんな複数のプロジェクトに関わっていて、常に多忙。残業時間もぎりぎりで何とかプロジェクトが回っている状態だよ。そんなみんなにさらに作業を増やすようなことを提案するというのかね？しかも、テストコードはお客様からしたら作っても作らなくても関係ない、いわば直接利益に関係ないような作業じゃないか。もちろん、世の中で認知されているということは知ってるよ？
毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン
手軽に負荷テストができるツール「Taurus」がスゴい
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
Software Design連載 2022年2月号 大規模Webアプリケーションの開発環境をモダナイズする - MonotaRO Tech Blog
こんにちは。モノタロウの八木(t_yagi)です。 モノタロウのECシステムは創業から20年以上ずっと動き続けており、絶え間なくビジネスを支え続けています。 その間、周囲のIT技術も大きく進歩してきました。 そんな中、開発者が増えたり機能も拡張され続けた結果、当初はさほど問題にならなかった開発に関する課題が浮き彫りになってきました。 今回はそんなレガシーな開発環境にモダンなIT技術を取り入れることで「当時は出来なかったことを現代の技術で実現する」を書きました。 流行りのモダンな技術がイケイケだから乗り変えるといったような輝かしいものではなく、長年積まれ続けてきた課題が現代の技術だから解決できたという時代の恩恵にうまく乗れるかを率直に記事にしています。 どうするとデメリットを抑えながらメリットを得ることができるか読んでいただける人に少しでも感じ取っていただければ嬉しいです。 サーバアプリの開
テストでのデータベース単位の捉えかた - 日々常々
データベース（に限らずあらゆる永続化リソース）を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで
メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング
こんにちは！ソウゾウの Software Engineer の @dragon3 です。 連載：「メルカリShops」プレオープンまでの開発の裏側の８日目を担当させていただきます。 この記事では、メルカリShops 開発において、日々バリバリに利用されている CI/CD 環境と Pull Request 毎のデプロイ環境について紹介します。 CI/CD 環境 メルカリShops では、CI/CD （テスト・ビルド・デプロイ）やその他自動化のために GitHub Actions を使っており、ほとんどのワークフロー・ジョブを Self-hosted runners で実行しています。 Self-hosted runners は、専用の VPC ネットワーク 内の GCE インスタンス上で動かしており、Managed Instance Group 等を使い、そのプロビジョニングや起動・停止等は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
