切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
Self-hosted GitHub Actions runners in AWS CodeBuild を試す
CodeBuild プロジェクトを使用して Webhook を設定し、GitHub ACtions ワークフローの yaml を更新して CodeBuild マシン上でホストされているセルフホストランナーを使用できる GitHub への認証は PAT か OAuth App を使う まとめというかわかったこと ※間違ってることや、こうすればいいよなどがあったらコメントください。 良かった点 セットアップは楽 ephemeral である 起動時間は EC2、Lambda 共に 1 分程度だった 個人的には十分速い マネージドイメージに加えて Docker カスタムイメージを指定可能 jobs.<job_id>.runs-on に -<image>-<image-version>-<instance-size> を追記すると、設定不要で様々なアーキテクチャのイメージを使える jobs.<job
マイクロサービスからモジュラーモノリスを経て新マイクロサービスへ - Techtouch Developers Blog
バックエンドエンジニア兼万年ダイエッターの taisa です。テックタッチは、以前マイクロサービスからモジュラーモノリスを経て新マイクロサービスへの切り直しを実施しました。本記事では、マイクロサービス・モノリスについて簡単に触れながらテックタッチがどういったプロセスでマイクロサービスの切り直しを実施したかを紹介します。 はじめに マイクロサービスとモノリス マイクロサービスとは マイクロサービスの利点 モノリスとは 単一プロセスモノリス モジュラーモノリス 分散モノリス テックタッチの場合 初期の頃の構成イメージ マイクロサービス切り直し前 特徴 モジュラーモノリス化 サービスの移行 別ドメイン境界でサービス切り直し イベントストーミング マイクロサービス切り直し後 DB 統合へ続く まとめ 参考 はじめに テックタッチは初期の頃からマイクロサービスアーキテクチャを採用していますが、一部の
はじめに こんにちは。雑食系エンジニアの勝又です。 今回は、私が2年ほど参画させていただいた大規模サービスのインフラやDevOps周りを全面的にリプレイスしたお話について簡単にご紹介させていただきます。(内容に関しては事前に参画先企業様に確認していただいております) サービス概要 詳細な内容は伏せますが、メインとなるテーブルのレコード数が数十億件、スパイク時には数万〜数十万のユーザーが一斉にアクセスする大規模サービスです。 技術的負債 長く運用されてきたサービスのあるあるですが、新機能の追加が最優先されてきたことにより、こちらのサービスにも下記のような技術的負債が大量に積み上がっていました。 RubyやRailsやMySQLのバージョンがかなり古い インフラの構成がコードではなくドキュメントで管理されている アプリケーションの構成管理がおこなわれていない CI/CDパイプラインが構築されて
開発生産性が上がるって分かったので GitHub Copilot Business を積極活用しています - Money Forward Developers Blog
エンジニアリング戦略室の高井といいます。 みなさん、GitHub Copilot は利用されていますか？ GitHub Copilot は GitHub と OpenAI が共同で開発した生成 AI を活用した開発支援ツールです。コードの自動補完、コード生成、ドキュメントの提案など、多岐にわたる機能を提供し、開発者の生産性を向上させることを目的としています。 マネーフォワードでは、昨年度にトライアルとして Copilot の利用を開始しました。本記事では、Copilot を利用して半年以上経過して、その利用がどのような効果をもたらしたかをレポートします。なお、ここで GitHub Copilot として言及されている Copilot のプランは GitHub Copilot Business です。 Copilot 利用状況・分析対象 なお、分析にはエンジニアリング組織のパフォーマンスを可
多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある
GitHub Actions でワークフローの同時実行を防ぐ concurrency 設定 - kakakakakku blog
GitHub Actions ではデフォルトの挙動として同じワークフローの複数のジョブを同時実行できる．無駄に待つ必要がないという意味ではメリットがあるけど，ワークフローによっては同時実行したくないこともあると思う． GitHub Actions でワークフローが複数トリガーされてしまって慌てて止めたという経験もあったりする😅例えばワークフローの実行時間が長く，完了する前に次のコミットをプッシュしてしまったり，ワークフローの実行が完了する前にプルリクエストをマージしてしまったり💨 concurrency 設定 GitHub Actions ではコンカレンシー (concurrency) という設定があって，ワークフローの同時実行を制御できる．今回はワークフローレベルで試すけど，ジョブレベルで細かく制御することもできる❗️個人的にはとりあえず設定しておいても良さそうかなと思う． docs
入門 継続的デリバリー
継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 序文 はじめに 第1部 継続的デリバリーとは 1章 『入門 継続的デリバリー』へようこそ 1.1 継続的デリバリーは必要？ 1.2 なぜ継続的デリバリー？ 1.3 継続的デリバリーとは 1.4 インテグレーション 1.5 継続的インテグレーション 1.6 何をデリバリーするのか？ 1.7 デリバリー 1.8 継続的デリバリーと継続的デプロイメント 1.9 継続的デリバリー
どのようにして Findy Team+フロントエンドチームは高速な開発をしているか 〜開発フロー編〜 - Findy Tech Blog
こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ のフロントエンド リードをしている @shoota です。 Findy Team+はエンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するための支援をしています。 そして（当然のことながら）Findy Team+ を作っている自分たちも、チームや個人でドッグフーディングをして、チームや自分自身の働き方やエンジニアリング組織の健康チェックをしています。 今回はそんな Findy Team+の開発チームのうち、フロントエンドチームがどのような開発環境・開発インフラで働いているかの概要をご紹介したいと思います。 フロントエンド技術スタックとCI高速化 技術スタック まずはじめにフロントエンドの技術スタックを簡単に紹介します。一般的なSPA構築の技術スタックを採
The Scary Thing About Automating Deploys - Slack Engineering
Most of Slack runs on a monolithic service simply called “The Webapp”. It’s big – hundreds of developers create hundreds of changes every week. Deploying at this scale is a unique challenge. When people talk about continuous deployment, they’re often thinking about deploying to systems as soon as changes are ready. They talk about microservices and 2-pizza teams (~8 people). But what does continuo
TL;DR RDS の メジャーバージョンアップグレード を行なった PostgreSQL 11.6 -> 15.5 MySQL 5.7.44 -> 8.0.36 PostgreSQL は AWS CDK を利用した、自前での手動切り替えをベースにした Blue/Green デプロイによるアップグレードを行なった MySQL は AWS コンソールから AWSが提供している機能である RDS Blue/Green Deployments による MySQL のアップグレードを行なった nginx の ngx_http_proxy_module を活用してサービスのダウンタイムを防止した はじめに 初めまして。株式会社ジーニーの GENIEE CHAT開発チームのマネージャーを担当しています。 今回は、データベースのメジャーアップグレードを行った際の手順やポイントなどを書いていこうと思います
自律型AIソフトウェアエンジニア「Devin」発表。課題から情報収集して環境構築・ビルド・デプロイまで | テクノエッジ TechnoEdge
ITジャーナリスト／Publickeyブロガー。IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。 AIスタートアップのCognitionは、自律型のAIソフトウェアエンジニア「Devin」を発表しました。 Devinは人間が課題を与えると、自律的に情報を参照し、コーディングやデバッグ、デプロイを行い、システム構築を実現するAIソフトウェアエンジニアだと説明されています。 Cognition AI CEOのScott Wu氏以下はデモ動画からのキャプチャです。 Devinは人間のソフトウェアエンジニアと同様に、自身のコンソール画面（右上）、コードエディタ（右下）、Webブラウザ（左下）を持っています（左上は人間とチャットでやり取りする領域）。 人間がプロンプトで何らかの課題を与えると、まず課題解決のためのプランを生成します。 今回、Dev
現在 estie では、デプロイの改善・統一に取り組んでいます。複数プロダクトのそれぞれの技術スタックが大きく違う中、どう考えたら効率的なデプロイを組めるのか。2024年のデプロイの原則について、あらためて考えてみました。
開発生産性と開発者体験の向上に向けた CI/CD改善の取り組み / proni-techbrew-in-tokyo-20240220
2024年2月20日実施のイベント登壇資料です。 https://findy.connpass.com/event/309537/ 【イベント概要 ※connpassより抜粋】 昨今、開発生産性を向上させるために、スピードと品質の両立のためにもテストやデプロイといった部分を自動化が進んでいます。資源の統一化、一元的な管理等の対応は急務であり、CI/CDの考え方や取り組みについて、様々な組織で工夫が凝らされています。 Findyでも、今後の取り組みを検討、改善していくユーザーの中で、「CI/CDに適したツールは何がいいのか」「他企業ではどういった取り組みをおこなっているのか」「現在のベストプラクティスは何か」といった声を多くいただいています。 本イベントでは、そういった声にお応えし、様々な企業での取り組み事例を、LTにて学び、明日から使える知見やノウハウの参考になる場を目指します。
SREエンジニアが目指すGKE共通デプロイ基盤の完成形 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう
デプロイ頻度やリードタイムの正確な計測にこだわらなくていい（前提はあるが） - mtx2s’s blog
デプロイ頻度とリードタイムは、開発チームが自らのパフォーマンスをモニタリングするうえで欠かせないメトリクスである。それらが、収益性や市場占有率といった組織パフォーマンスに影響を与えるからだ。その調査結果は、DevOps Research and Assessment（DORA）が特定した4つのキーメトリクス、いわゆる「DORAメトリクス」の要素として浸透した（後述するが、DORAメトリクスで扱うのは、リードタイムではなく「変更のリードタイム」である）。 その重要性ゆえに、チームや組織はこれらのメトリクスの計測と可視化に努める。可能な範囲で正確な値が欲しい。そうして、チケット管理ツールやバージョン管理システムからテレメトリを収集、集計し、チームのモニタリングダッシュボードにその実績値を可視化するのだ。 しかし、しばらくメトリクスを運用してみると、その扱いづらさに気づく。計測値や集計値のばらつ
まずはドメインごとにデプロイ可能とする ～ドメイン間の依存が複雑なモノリスのモダナイズに向けて～ - MonotaRO Tech Blog
こんにちは。コアシステムエンジニアリング部門で受注システムの開発を担当している中尾です。 今回はモノタロウの基幹システムのモダナイゼーションの取り組みについて紹介します。 モノタロウ社内の基幹システムにはいくつか存在しておりますが、中でも古くに作られた大規模なシステムについて、機能や開発に関係するグループが多く、保守コストが増大している状況にあります。 そこで、この度、業務ドメイン毎に開発・保守できるような体制の構築とシステムの分割を実施しましたので、その取り組み内容を紹介いたします。 背景 現在、MonotaROではお客様向けのWebサイト以外に、間接業務で利用するシステムやサイトに掲載する商品や発注・在庫の管理をするシステムが存在しており、これらを社内では基幹システムと位置づけています。一般的に基幹システムはパッケージを導入していることも多いですが、MonotaROでは一部の基幹システ
デプロイ対象環境ごとに別々のSlackチャンネルに通知するGitHub Actionsの実装例 - KAYAC engineers' blog
SREチームの長田です。 SRE関連の記事としては今年最初の記事になります。 今年も定期的にSREチームメンバーによる記事を投稿していく予定です。 よろしくお願いします。 さて、今回はGitHub Actionsのはなしです。 TL;DR デプロイを実行するGitHub Actionsの実行状況を デプロイ対象環境ごとに別々のSlackチャンネルに通知する場合の実装例として、 「slackapi/slack-github-actionで通知をつくりこむ」 「Actions Workflowを分ける」 「Actions Workflow実行の入り口を分ける」 の3つを紹介します。 背景 カヤックでは「まちのコイン」という地域通貨サービスを開発・運用しています。 coin.machino.co まちのコインの開発・運用チームの、特にサーバーサイドに関しては、 アプリケーションやインフラ構成の変
どうも、Repro Core Unit に所属している村上です。 Repro では現在、20 を超える Kafka Streams アプリケーションが稼働しています。 その中の半分くらいが Repro システムの共通基盤を構成する Kafka Streams アプリケーションであり、それらの運用は Repro Core が持つ責務の 1 つとなっています。 この共通基盤となる Kafka Streams アプリケーション群は、Gradle のマルチプロジェクト構成になっていてコードベースはモノレポで管理されています。 本稿では、この構成におけるデプロイ性の課題とそれに対するアプローチの話をします。 ディレクトリ構造 共通基盤のコードは以下のようなディレクトリ構成になっています。 . ├── Base ├── Deployments A │ └── Kafka Streams Applica
リリース頻度を毎週から毎日にしてみた - NTT Communications Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
はじめに 僕はDeno Land Inc.でDenoを利用したサーバレスエッジホスティングサービスのDeno Deployを開発するチームに所属しています。OSSのほうのDenoのメイン言語はRustで、Deno Deployのバックエンドも同様にRustで書かれています。 今年のアドベントカレンダーで一休さんから以下の記事が公開されましたが、日本でもRustをWebバックエンドの言語として採用する企業がじわじわと増えてきている印象があります。 Deno DeployのバックエンドをRustで開発してきて、RustでWebバックエンドを書くことのメリットやデメリットをいくつか感じたので、この記事で紹介したいと思います。 Deno Deployの構成 まず、ざっくりとDeno Deployのバックエンドの構成を紹介します。 多くのコンポーネントがありますが、ここではどのようにRustを利用し
はてなブックマークのステージング環境を支える技術 - Hatena Developer Blog
id:cohalzです。この記事ははてなエンジニア Advent Calendar 2023 の29日目の記事です。 28日目の記事は id:SlashNephy さんの おうち Kubernetes クラスタ運用記 ~2023~ でした。 はてなブックマークにおけるステージング環境について紹介します。 はてなブックマークでは現在インフラをAWS上に構築しており、ECSやAurora MySQLのサービスを利用しています。 本番環境と同様にステージング環境も用意していますが、より良いステージング環境(例えば本番環境に近く、変更がすぐ試せて、費用が安い構成)にすることを目指し、いくつか工夫した点があるのでそれらを紹介します。 AWSアカウントの分離 はてなでは複数のサービスを運用していますが、はてなブックマーク単体でAWSアカウントを分けて他のサービスとリソースが同居しないようにしています。
株式会社ゆめみの23卒 Advent Calendar 2023 の 22日目の記事を書きました はじめに 今見ているあなたは趣味で行った開発の中でデプロイしユーザーに使ってもらった経験はありますか？ 「趣味で開発してたものはあるが、実際にデプロイしたことがない」「デプロイしたものもあるが、デプロイできるまでやり通すことの方が珍しい」という方がほとんどだと思います。 また趣味で行っている開発についての話題になると、「やる気があるうちにデプロイした方が良いよね～」みたいな話題になると思うのですが、そう思っていながらも実際に意識して取り組む方はなかなかいないと思います。 今年の趣味開発を考えている時に Discord で使用できる Bot を作成して運用したいな～と思っていたのですが、私も趣味で開発していたものを途中でやめてしまうことがほとんどだったので、今回の開発はまずデプロイという事を意識
ニーリーのSREによるリリースサイクルの改善〜「隔週深夜1回→1日2回」にリリース頻度を向上させた道のり〜｜株式会社ニーリー公式note
プロダクト開発グループSREチームの大木（おおぎ）と菊地です。 突然ですが、皆さんのプロダクトではリリースはどのように行われていますか？ 実は、ニーリーのメインプロダクトであるPark Direct（パークダイレクト）はわずか1年前まで隔週に一度、深夜0時からしかリリースを行うことができていませんでした。開発組織の健全性の指標として使われる d/d/d (deploys / a day / a developer) という指標で、1年前の我々は d/d/d=0.015ぐらいのスコアでした。この指標は d/d/d >= 0.1 が健全な組織としての目安となるそうです（※1）。かなりの開きがありますね・・・。 この記事では、SREチームのリリースエンジニアリングと開発チームのプロセス改善により、リリースの頻度が大幅に向上したというお話をしたいと思います。 ※1 『エンジニアリング組織論への招待
なんと、12/02 付けで @tacrew さんが投稿された記事とネタ被りしてしまいました笑 記事をほぼ書いた後に気づいたのですが、ある程度書いていたためこのまま投稿します。 内容は近いですが、req-suit や Storybook を使ってる点は本記事と全く異なる部分になります。 ぜひご参考ください！ GitHubだけでVRTする仕組みを作ってみた #GitHub - Qiita TL;DR 対象 ビルド・デプロイを GitHub Actions で行っている VRT を導入したい しかし Amazon S3 などの外部サービスに依存したくない。 VRT の細かい方法がある程度わかっている（VRT の細かい方法については割愛しています） GitHub Actions のキャッシュにスクリーンショット（スナップショット）を保存することで、外部サービスに依存せずシンプルに VRT を導入す
これはエムスリーAdvent Calendar 2023 の10日目の記事です。 こんにちは、エンジニアリンググループの石塚です。最近は年明けに控えている結婚式という大イベントに向けてダイエット中でスポーツジムへ通い、有酸素運動するのと並行して食事制限をして追い込んでいる毎日です。2ヶ月ほどで6kg弱の減量を目標に地道に日々目標をスプレッドシートにまとめながら追い込んでます。(今の所良いペースです。) 今回は、弊社で利用しているLookerというBIツールを利用しているなかで発生したつらみの共有と対策について共有します。少しニッチな内容ですが、自分自身が調べているときに同事象で苦しんでいるようなブログ記事が見当たらなかったこともあり、ニッチな人を対象に有益な内容になれば幸いです。 11/6からの体重減少とランニング累計の記録をグラフにしました。 Lookerとは？ デプロイに成功したのに想
カナリアリリースに関連のある部分を図に起こしたものが以下です。 ECSクラスターの中にあるサービスに対してターゲットグループを設定し、ALBからのリクエストをタスクに割り振っています。 デプロイはGitHub ActionsのWorkflow Dispatchを使用し、ボタン押下で実行できます。このプロセスはDockerイメージをビルド、Amazon Elastic Container Registry（以下、Amazon ECRと表記）にイメージをプッシュし、Amazon ECSのタスク定義を更新すると自動的にタスクのローリングアップデートが走る仕組みを使用しています。 余談ですが、クーポンサービスでは以前Spring Boot 2.6を採用していました。 Spring Bootの3系へのアップグレードについては記事「出前館クーポンサービスでのサーバーアプリケーションのSpring Bo
DevFest Tokyo 2023: Google Cloudでチームで安全にデプロイをする
DevFest Tokyo 2023: Google Cloudでチームで安全にデプロイをする https://gdg-tokyo.connpass.com/event/301690/ サンプル https://github.com/sakajunquality/devfest-2023
「Startup Day 2023」は日本中のAWSを利用するStartupが、AWSの知見を披露するHubとなる1日です。2023年はサブテーマに「スタートアップ冬の時代を共に乗り越える」を掲げて、スタートアップが面しているこの逆境をどうやって跳ね除け、成長につなげていけるかを共有します。ここで、株式会社メイツのk.goto氏が登壇。続いて、CDKの便利機能について話します。前回はこちらから。 CDKの便利機能 （L2,L3）コンストラクト k.goto氏：次に、CDKの便利機能を1個ずつ紹介していきます。まずはL2、L3コンストラクト。まずコンストラクトが何かというと、CDKの独自機能や独自概念という感じです。ソースコード上でいうと、CDKの独自クラスによるAWSリソース定義の抽象化をしてくれるものです。 L1、L2、L3というようにレイヤーが分かれていて、数字が大きくなる、上にいくほ
成果物のハッシュ値を保存・比較して余計なデプロイを行わないようにする for GitHub Actions
タイトル通りです。GitHub Actions において、成果物のハッシュ値を保存・比較して余計なデプロイを行わないようにする方法を記します。 TL;DR 対象 ビルド・デプロイを GitHub Actions で行っている 余計なデプロイはしたくない 静的サイトのビルド時に成果物のハッシュ値(sha256)を計算して、前回のデプロイ時と同じであればデプロイをスキップする ファイル 1 つ 1 つのハッシュ値を計算し、全ハッシュ値からさらにハッシュ値を計算する コマンド find <成果物のあるディレクトリパス> -type f -print0 | sort --zero-terminated | xargs -0 sha256sum | cut -d ' ' -f 1 | sha256sum | cut -d ' ' -f 1 デプロイ時に計算したハッシュ値は GitHub Action
記事中のURLプレビューを実装した (Cloudflare Pages Functions) | Marginalia
記事中のURLプレビューをiframeで表示するためのエンドポイントをCloudflare Pages Functionsで実装した。実はこれまで長らくはてなブログのembed APIを勝手に借りていた。倫理的によろしくない面もあったり、パフォーマンスや信頼性の面でもセルフホストしたいと思っていたが、着手するのを先延ばしにしていた。別に技術的に困難なポイントがあったわけではないが、備忘録としてやったことを書く。 /embed エンドポイントの作成このブログはCloudflare Pagesでホスティングしている。Cloudflare PagesのFunctions機能は、デプロイするレポジトリの /functions ディレクトリの中に配置したスクリプトを動的なWorker関数として呼び出せるようにしてくれる。 今回はこの機能を使って、 /functions/embed/index.tsx
Uber、4000以上のマイクロサービスをKubernetesとMesosを実行する新しいマルチクラウドプラットフォームに移行
Mark Fussell氏とYaron Schneider氏とDaprを知ろう 本日のエピソードでは、Thomas Betts氏がMark Fussell氏とYaron Schneider氏に、分散アプリケーション・ランタイム（Dapr）について話を聞いた。最新のInfoQ Architecture and Design Trends Reportでは、Daprはポータビリティとクラウドアプリケーションのための設計というアーリーアダプターのアイデアの一部となっている。
はじめに こんにちは！！@Sicut_studyです！ クラウド破産しかけました！ギリギリ払えるくらいやばかったです！！ 普段サービスを Firbese でデプロイしているのですが、この度自分でサービスをリリースした時に破産しそうになった話を共有していきます。 自分が使うためのサービスとみんなに利用してもらうためのサービスではこの点が大きく違うんだなとしみじみ感じたので、自分以外が使うサービスをリリースする方には参考になるかと思います 0. アラートは突然に とあるメールが自分のもとに届きました !?!??!??!??!?!!!?? やばいまだ11月始まって6日なのに予算の半分を使ってしまっただと！？！ とくにリリースなどは行っていなかったのでなぜか今月になって請求額があがるようになっていました 仕事中にメールが来たのですが、気になりすぎてまったく集中できませんでした😅😅😅😅 1.
学園祭で売上をリアルタイムに公開するサイトを雑に作ると盛り上がる - いなにわうどん
先日の学園祭で友人のオタク達とやきそばを焼いて原価ギリギリで売ったところ予想以上の盛況でした*1。色々と工夫点はあったのですが、その一つとして売上杯数を Web 上で登録してリアルタイムで雑に public internet に公開するという試みをしてみところちょっと盛り上がったため、その経緯を書いていきたいと思います*2。 つくったもの 会計を登録するシステムとその集計結果を表示する Web サイト（＋付随する簡単な API）を作りました。フロントエンド側のコードは GitHub 上に公開しています*3。 github.comサイトは以下のページから構成されます。フロントエンドはすべて public になっているため、簡易的な認証として API 側で Authorization ヘッダ内のトークンの有無を検証し、不正なトークンが送付された場合は 401 を返す設計としました*4。 トーク
「インフラ技術基礎勉強会 #4」は、業務改善、業務効率化、自動化をテーマにした勉強会です。ここで「GitHubActionsで構築した自動化の仕組み」をテーマに奈良氏が登壇。GitHubActionsの基本と、AWS環境へのデプロイとテストの自動化について話します。 奈良氏の自己紹介 奈良貴充氏：こういった機会をいただきありがとうございます。「GitHubActionsで構築した自動化の仕組み」と題して、今回話します。よろしくお願いします。 今回ですが、7つのアジェンダでお話しします。「GitHubActions」を使っている方も多いと思うので、「こういったケースで使っているんだな」と聞いてもらえればと思います。 まず自己紹介します。私は凸版印刷というところで仕事をしています。主に新規サービスの立ち上げに関するシステム開発全般を扱っています。好きなものは日本のサブカルじゃないですが、漫画、
AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり - Kengo's blog
Accelerate 第1版（以下単にAccelerateと呼ぶ）はDevOpsに関するトレンドを抑えるうえで基本となる本なのですが、もはや古く最新の知見が書いてあるとは言えません。State of DevOpsは毎年アップデートされているのですがコンテキストを丁寧には抑えてくれず、背景を含めて読み解くのが難しいという印象があります。どうもAccelerate 第2版がそろそろ出るらしいんですが、とりあえず現時点での自分の理解をまとめておきます。 端的に言うと、これらは安定したソフトウェアを高速に顧客に提供できる良い開発チームの特徴を踏まえ、皆さんの組織で再現可能にするための研究であり指針です。当然「良い開発チームがあれば常に良い問題解決ができる」というわけでも「ここで定義された良さが組織問わず普遍的である」というわけでもありませんが、顧客の課題に立ち向かうための組織設計において良い仮説を
こんにちは。弊社のエンゲージメントサーベイ製品HR Spannerのリードエンジニアを担当している岡部です。昨今注目されているDevOpsとそのケイパビリティについて、およそ一年前に社内の勉強会で発表を行ないました。今回の機会に、こちらでも寄稿させていただきたいと思います。 元になっている書籍は比較的大規模な開発を対象にしていると思いますが、当社のHR Spannerは10名程度の比較的小規模な開発であり、それを前提とした内容になっています。 DevOpsとは何か？ 書籍「LeanとDevOpsの科学」では大規模アンケート調査により、高収益、高利益率、高市場占有率を持つ企業は、単に起業家精神やM&Aの取り組みだけでなく、開発組織におけるDevOpsのケイパビリティを強化している傾向が浮かび上がっています。この結果は単なる相関関係ではなく、統計手法によって因果関係として確認されています。また
Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約
Next.js に対する Kent C. Dodds の批判と、Lee Robinson のアンサーの要約 はじめに 10 月 26 日に Next.js Conf が開催されましたが、それと前後して Kent C. Dodds (以下 kentcdodds と呼びます) と Lee Robinson (以下 leerob と呼びます) がそれぞれ という記事を公開しました。前者はタイトルの通り、Testing Library の作者であり、Remix の共同創業者の一人でもある開発者兼教育者 kentcdodds が、Next.js を使わない理由について述べたものです。そして後者は、Vercel の VP of Developer Experience である leerob が、主に前者に対する反論を述べたものです。筆者は両方の記事を公開後すぐに面白く読み、そしてどちらにも頷けるところ
株式会社HighLink ロジスティクスエンジニアのかんたろう(@kantarow)です。 私たちは複数のチームで一つのステージング環境を利用しています。masterブランチが更新されるごとにステージング環境へのデプロイが行われ、リリース前には必ずここで動作確認を行います。 このmasterマージによるデプロイには問題が無いのですが、master以外のブランチの動作確認を行うために手動デプロイを行った場合、ステージング環境での検証が中断される問題が起こります。 そこで、Pull Requestごとに自動で検証環境を立ち上げる仕組みを構築することで、この課題を解決しました。 本記事では、この解決方法に至った経緯と、運用を始めて改善されたことをご紹介します。 これまでのリリースフローの問題 カラリアの開発では、masterにマージされた変更が自動でステージング環境にデプロイされ、担当する開発者
◆ Live配信スケジュール ◆ サイオステクノロジーでは、Microsoft MVPの武井による「わかりみの深いシリーズ」など、定期的なLive配信を行っています。 ⇒ 詳細スケジュールはこちらから ⇒ 見逃してしまった方はYoutubeチャンネルをご覧ください 【4/18開催】VSCode Dev Containersで楽々開発環境構築祭り〜Python/Reactなどなど〜 Visual Studio Codeの拡張機能であるDev Containersを使ってReactとかPythonとかSpring Bootとかの開発環境をラクチンで構築する方法を紹介するイベントです。 https://tech-lab.connpass.com/event/311864/ みなさん、こんにちは。サイオステクノロジー武井です。今回は、今話題沸騰の生成AIサービスであるAzure OpenAI Se
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
大規模サービスのインフラを全面的にリプレイスした話 - Qiita
今のチームに来てから最も生産性が上がった考え方｜牛尾 剛
Blue/Green デプロイを使用した、RDS MySQL/PostgreSQLのアップグレード
デプロイ再考2024/reconsidering-deploy-in-2024
マルチプロジェクト構成リポジトリにおいて変更の影響を受けるプロジェクトを検出する - Repro Tech Blog
RustでWebバックエンドを書き始めてから1年くらい経った
作りたいものは作り始める前に今すぐにデプロイしよう - Qiita
GitHub Actions のキャッシュを使った VRT のすゝめ
Looker APIを活用して確実なデプロイを実現させる - エムスリーテックブログ
Amazon ECSにおけるカナリアリリースの実現
自動的・機械的サポートが豊富にある「AWS CDK」 生産性向上につながる7つの便利機能
Next.jsをFirebaseにデプロイしたら高額請求がきて貯金がなくなりかけた話 - Qiita
「やはりGitHubActionsは使ったほうが良い」 AWS環境へのデプロイとテストを自動化して感じた効果
組織をハイパフォーマーにするスキル、DevOps - techtekt
プルリクエストごとに検証環境が立ち上がるようにした話 - High Link テックブログ
世界一わかりみの深いAzure OpenAI Service | SIOS Tech. Lab