タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
こんにちは、Sally社 CTO の @aitaro です。 マーダーミステリーアプリ「ウズ」とマダミス制作ツール「ウズスタジオ」、マダミス情報サイト「マダミス.jp」を開発しています。 はじめに この記事ではウズの開発当初から利用していた Docker Compose をやめることにした背景についてご紹介します。 Docker Compose は各マシンの開発環境での差異を吸収するというメリットがあり、多くの開発現場で導入されていますが、Docker Composeの抱えているデメリットを勘案して、最終的に一部を残して辞める決断をしました。 Docker Composeの特徴 Docker Composeは、複数のコンテナを定義し、管理するためのツールです。ウズの開発環境では、バックエンド、フロントエンド、データベースなどをそれぞれコンテナ化して、Composeで一括管理していました。こ
TypeScriptのモノレポ構成を考える
はじめにlink あまりモノレポの構成について語られている記事が多くないなと感じたので、現時点で自分が考えている設計をまとめてみる。 以前にTwitterでディレクトリ構成と内容については言及したが、実際に利用する技術についてはあまり触れなかったので改めて検証してみた。 https://twitter.com/koh110/status/1617510034266808322 クライアントサイドとサーバーサイドのコード共有については下記の記事がよくまとまっていた。 https://capelski.medium.com/effective-code-sharing-in-typescript-monorepos-475f9600f6b4 上記の記事の構成も参考にしつつ、自分の考えも加えて検証していく。 相対パスを利用する方法 npmのローカルパス指定（file:xx）を利用する方法 シンボ
※本記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud Platform（GCP）であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と
それっぽいタイトルを付けましたが特に意味はないです。 workspace を使ったコマンドを最適化して実行する Turborepo についてのお話で Turborepo を軽く触ってみた際にnpx create-turbo@latestで作られる構成がとてもわかりやすく、プロダクトの初期段階からモノレポを採用するのは選択肢の 1 つとしていいのでは、と思い続編を書きました。 前回と同じくサンプルのリポジトリはこちらになります。 https://github.com/nus3/p-turborepo/tree/main/yarn 概要 モノレポを採用することで、同一リポジトリ内で自作した汎用的なライブラリやコンポーネントを複数のアプリケーションで使いまわせる モノレポの規模が大きくなってきた場合には、モノレポ内のパッケージを npm に公開することでアプリケーションとパッケージを非同期に開発
散らばったAWS LambdaのGitHubリポジトリをモノレポ構成にしてメンテナンスコストを削減する - クラウドワークス エンジニアブログ
初めまして。crowdworks.jpのSREチームに所属しています @ciloholic です。 入社してかれこれ1年経ちますが、筆を執る機会がなかったため、今回が初エンジニアブログとなります。 この記事では、入社して3か月ほど行なっていた「AWS Lambda周りのメンテナンスコスト削減」の取り組みを紹介していきます。 背景 crowdworks.jpでは、多くのエンジニアがさまざまなGitHubリポジトリに色々な言語でLambdaを活用してきました。GitHubリポジトリは30個以上、使用言語はNode.js / Ruby / Goとさまざま、CI/CDもCircleCI / GitHub Actionsとバラバラです。 SREチームでは、定期的に各種言語のEOL対応やライブラリのアップデート作業を行なっているのですが、GitHubリポジトリもそれぞれ異なる、使用言語もCI/CDもバ
こんにちは、ヘンリーの Lead Architect の @kohii です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 最近 Henry のバックエンドをモノレポ化したので、その戦略やプロセスについて書きたいと思います。 こちらは前編となっており、モノレポ移行の手法やテクニックの話は後編で説明します。 dev.henry.jp Why モノレポ？ ざっくり説明すると、既存のマイクロサービス/チームの分界点を抜本的に見直し、ドメイン（業務の領域）による分割を目指すため、一旦モノレポにまとめて、理想的な構造の切り出しをやりやすくするという目的です。 モノレポ化前のシステム/チームアーキテクチャ バックエンド Henryのバックエンドはマイクロサービスになっていますが、以下の2つのサービスが大部分を占めています。 henry-general-api …
Bun workspace で始めるモノレポ生活
Bun workspace で始めるモノレポ生活 2023.09.15 Bun では `package.json` の `workspaces` を使用することでモノレポの管理が可能です。この記事では Bun によるモノレポを試してみます。 Bun はパッケージマネージャーとしても利用できるので、npm の workspaces によるモノレポ管理も可能です。モノレポとは、複数のパッケージを 1 つのリポジトリで管理することです。モノレポを利用することで、同レポジトリ内のパッケージを互いに参照したり、node_modules をシェアしてディスク容量を節約するといったメリットがあります。 この記事では、Bun workspace を利用してモノレポを管理する方法を紹介します。 Bun workspace の使い方 workspace ではディレクトリのルートレベルに、各パッケージを管理する
[TypeScript]モノレポ管理ツール比較検討
モノレポ管理のツールを検討したときのメモ Background 自分が所属するチームで開発する JavaScript/TypeScript のプロダクトが増えてきて、同じような内容のリポジトリがいくつも存在している（n個とする）。 変更を加えていくにつれて、それぞれの差分が大きくなり、以下のような問題が発生する。 開発が止まっているプロジェクトの構成が古くなり、修正コストが発生する 開発が複数同時進行している場合、同じような実装を手動で同期する必要がある これらは共通の基盤等があれば効率的に（理想的にはn分の1の労力で）開発が可能であり、将来的なコストを考えると、いまのうちにその仕組みを考えておきたい。 Proposed Solutions 要件は以下 複数のパッケージをnpmとしてpublishできる アプリケーションも管理できる Nx, Rush, Lerna を主要な選択肢としている
![[TypeScript]モノレポ管理ツール比較検討](https://cdn-ak-scissors.b.st-hatena.com/image/square/e204665caf2bdc344987086461dd0424f7c8112d/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--mp4vbqB0--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BTypeScript%25255D%2525E3%252583%2525A2%2525E3%252583%25258E%2525E3%252583%2525AC%2525E3%252583%25259D%2525E7%2525AE%2525A1%2525E7%252590%252586%2525E3%252583%252584%2525E3%252583%2525BC%2525E3%252583%2525AB%2525E6%2525AF%252594%2525E8%2525BC%252583%2525E6%2525A4%25259C%2525E8%2525A8%25258E%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Aokmttdhr%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2I5NmZlMjc4YTYuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
重要な追記 sparse checkout して、git diff で判定、というのがこの記事の主な趣旨だけど、自分が on.push.paths の存在を知らなくて、これを使うと、次のように sparse checkout するだけでよかった。 # .github/workflows/foo-test.yaml name: foo-test on: push: paths: systems/foo/** env: SPARSE_CHECKOUT_DIR: systems/foo jobs: test: runs-on: Ubuntu-20.04 steps: - name: sparse checkout run: | git clone --filter=blob:none --no-checkout --depth 1 --sparse https://${GITHUB_ACTOR}
タスク数100超え！モノレポとエスプレスタックで支えるECS管理の仕組み（ecspresso/ecschedule） - ウェルスナビ開発者ブログ
ECSの運用で発生した悩み リポジトリ分割と採用ツール 採用したツール モノレポ管理 jsonnetの利用イメージ パイプラインの実装 差分検出 反映の高速化 crontabのJST表記対応 ecspresso verifyによるチェック OPAによるポリシーチェック さいごに こんにちは、インフラエンジニアの和田です。 弊社は、WEBアプリケーションおよびバッチ処理の実行基盤として Amazon Elastic Container Service（以下「ECS」と呼ぶ） を採用しています。現在では複数チームの開発者が 100 を超えるタスク定義を運用する規模にまで拡大しています。この記事では、増え続けるECS定義をモノレポとエスプレスタック（ecspresso/ecschedule）で管理した事例を紹介します。 ECSの運用で発生した悩み ECSを利用する開発者やアプリケーション数が増え
モノレポについて経験豊富そうな皆さんの話を聞きたい。 まずはその背景から。 会社で分かれるレポジトリ フリーランスをやっていると、たまにいろんな零細企業を集めて一つのサービスを作る場に遭遇する。 人を集める時に、一つの会社だけじゃなくて複数の会社が集まることがよくある。 たとえばマーケティングが強みの会社が自社ではエンジニアを持っていなくて、開発は外部の人たちを集めてやるみたいな。 しかもそれぞれの会社からは一人とか二人だけしか来ないので、 6人の小規模なチームなのに会社は4つあるとかいう状況になったりもする。 そうすると何が起こるかというと、レポジトリが会社ごとに分かれたりする。 「クラウドとフロントの間はAPIを決めましょう、 それでクラウド側がバイナリをリリースして、フロント側がたまにそれをマージしましょう」みたいなフローになる。フロントとバックエンドなんて関わっているのは3人しか居
詳しい方いたら教えてください。めっちゃ欲しい情報ですん。 別にモノレポでなくてもいいんですが、backend/frontendをTSで開発されてる場合Prisma入れてる気がするのですがそういう時の型共有の方法、ggってもあまり出てこない気がする。 Prisma とは Node.jsのORMです。かなり使いやすくて気に入ってます。 スターもたくさんついてますね。 お金もたくさん調達できてるみたいでいい感じです。 Prismaの型の生成 参考: Set up Prisma 上記ページをもとにサクッとinstallすると /prisma に schema.prismaというファイルが生成されます。そのファイルに、例えばこんな感じでスキーマを定義してみます。 // ユーザー model User { id String @id @default(cuid()) slug String @uniq
こんにちは、ヘンリーの SRE の戸田と Wildcard Engineer の岩永です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 前編の Henry のバックエンドをモノレポ化した戦略やプロセスに続いて、後編のこちらの記事ではモノレポ化の技術的手法を解説します。 dev.henry.jp 実際のモノレポ化の流れに沿って、ポイントを3点説明します。 2つの git リポジトリのマージ アプリケーション・ワークフローのモノレポ対応 モノレポへの切り替え当日に向けた手順書の作成 1. 2つの git リポジトリのマージ 今回のモノレポ化においては、もともと存在していた henry-general-api と henry-receipt-api という2つのマイクロサービスのリポジトリを、1つのリポジトリにマージし、それぞれのマイクロサービスがサブディレ
多数のインフラ関連リポジトリをモノレポ構成にまとめたTips - LIVESENSE ENGINEER BLOG
前書き リブセンス インフラエンジニアの中野(etsxxx)です。VPoEという肩書きのそいつと同一人物です。 言うまでもなく写真と本文にはあまり関係ありません。コロナ禍前の、弊社のオフィスでのモノレポ化の風景です。 写真のそれとは異なりますが、私はTeacher'sというウィスキーを家に常備しています。Zoomで烏龍茶を飲んでるように見えたらそれはTeacher'sです。これ、2,700mlサイズのペットボトルが売られていて、それを徒歩5分以内の店で2,700円ほどで買えることを知ってから、そればかり買っています。2,700mlもあれば当分大丈夫だろうと思っていると、いつのまにか空になっているから、リモートワークはなかなか気が抜けません。 さて、Google、Facebookが、モノレポ(monolithic repository/単一リポジトリ)を採用しているという噂は広く知られている
モノレポでマージキューと必須ステータスチェックを運用するためのTips - ROUTE06 Tech Blog
ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 GitHub のマージキュー(Merge Queue)を私のチームでの開発フローに取り入れてから数ヶ月経ちました。マージキューは非常に便利ですが、挙動の理解やセットアップに難しさがあると感じています。いくつかの課題の対処ができ安定した運用ができてきたので、この記事ではセットアップでつまづきがちな点を紹介します。 マージキューとは マージキューは 2023 年 7 月に一般公開された比較的新しい機能で、簡単に説明すると「プルリクエストのマージ前にマージ先ブランチを取り込んだ上で CI を実行し、通ることを確認してからマージする」機能です。 複数人で GitHub を利用した開発をしていると、main ブランチの取り込み漏れにより「プルリクエストでの CI は通るものの、マージ後の main ブランチの CI は失敗する
モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました | Graat（グラーツ）-グロース・アーキテクチャ＆チームス株式会社
モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました unsafe:このドキュメントは、モノレポについて書かれた記事 Misconceptions about Monorepos: Monorepo != Monolith (https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c) を、筆者であるVictor Savkin氏の許可を得て翻訳したものです。 複数のプロジェクトを同一のリポジトリで運用する モノリシックリポジトリ（モノレポ）― この記事では、モノレポを使う際によくある誤解とその対策、モノレポが持つ本当の課題と利点がまとめられています。モノレポはガチガチの「一枚岩（モノリス）」
マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog
Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は（使い古されたネタではありますが）モノレポ化についてお話ししたいと思います。 おさらい：モノレポ（mono repo）とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ（poly repo）と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること
deno で CLI ツールを作っていたら楽しくなって色々作っていた。 課題: モノレポの諸々の操作がだるい npm/pnpm/yarn の workspace を使っていると、次のようなディレクトリ移動が段々面倒になってくる。 foo を build して bar を build してルートから bar のテストを流す、みたいなことをするとこういう感じになる。 $ cd packages/foo $ pnpm build $ cd ../bar $ pnpm build $ cd ../.. ## コマンドの中身を確認 $ cat package.json | jq ".scripts" { "test": "pnpm test:foo && pnpm test:bar", "test:foo": "cd packages/foo && pnpm test", "test:bar": "
はじめに みなさんこんにちは、物流業界の価値最大化をミッションに掲げ運送会社のDXに寄り添うアセンド株式会社でCTOを務めている丹羽です。 1日5.2回のリリースを実現するプロダクトチームの開発体験を支えるCIの高速化についてご紹介します（先週3/20週の平均値）。1日に数回デプロイというレベルでの素早く開発するにおいて、 push 時の CI Check の速さは地味ですが開発体験にとって見逃せない存在になります。特にモノレポ環境ではジョブが複数ある中でいかに省略ができるかが鍵となり、泥臭くも数十秒でも高速化のため戦ったポイントを紹介します。 アセンドでは顧客課題を中心にプロダクト開発をするためにフルサイクルエンジニアという開発スタイルを取り、１エンジニアがフロント・バックエンドだけでなく設計からリリース・サポートまでのソフトウェアのライフサイクル全体にオーナーシップを持って開発していま
Rustを使ってCLIとVSCode拡張を同時に作ってみたよという記事です！ ここで言う「同時に作った」とは「CLIとVSCode拡張に共通するコアの処理をRustで実装し、CLIはコア処理以外もRustで実装する一方、vscode拡張はTSベースで実装してコア処理はWasmに変換して呼び出す実装にした」という意味です。 それをモノレポでやってみて、けっこう色々いい感じだった＆勉強になったので記録を残しておいてみます👶 なお、ツールのアイデアをくれたtaisaさん、Wasmを使うアイデアをくれたyokoishiさん本当にありがとうございました！ 作ったもの MySQLのINSERTクエリをテーブルのような見た目に、つまりカラム名と各行の値がタテ方向に並んで見えるようフォーマットするというものです。 自分の勤め先ではテストデータを大量のINSERTクエリで表現する場面がしばしばあり、地味な
自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手
サービス成長と共に肥大化するモノレポ、長くなるCI時間 / As services grow, monorepos get bigger and CI time gets longer
SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/
こんにちは。フルーリオ株式会社のlumaです。 Node.jsプロジェクトで開発をする際に役立つフルーリオ株式会社の新作CLIツール notios の紹介をします。 notiosの読み方は「ノーティオス」です。 対象読者 Node.jsでモノレポでの開発をしている npm-run-allを利用している Node.js開発で開発コマンド(next dev 、nodemon 、 node-dev)stdoutとstderrが混在しているのを解消したい すぐに導入したい人はこちら npm-run-all を利用している場合は、 npm remove npm-run-all npm install -D notios package.json が置いてあるディレクトリで npx notios yarn や pnpm でも問題なく使用できます。また、 npx notios 経由で起動していない場合は
3ヶ月で120のリポジトリを1つのMonorepo(モノレポ/モノリポ)に移行した話 - asoview! Tech Blog
PolyrepoとMonorepo これはアソビュー！ Advent Calendar 2022の23日目です。 アソビューでVPoE兼Tech Leadをしているdisc99🐼です！ 今回は、Monorepo運用の事例紹介をさせてもらえればと思います！ アソビューではほぼすべてのGitリポジトリを統合したMonorepo運用を2年以上行っています。 最近では特定の技術領域やプロダクトに対してMonorepoを適用した事例は増えてきています。 しかし、社内のほぼすべてのソースコードを1つのMonorepoで管理している組織はまだ多くないと思いますので、参考になれば幸いです。 今回はなぜMonorepoに移行したかや、具体的にどのような管理をしているか、また今後の展望などを公開します！ 🐣なぜMonorepoなのか 背景 Monorepoとは？ 素早さ 分かりやすさ 管理のしやすさ その
はじめに AI Team MLOps Engineer の西原です。前回は kubeflow pipeline(kfp)のローカル環境での実行について Tech Blog を書きました。kfp は 2024 年に入ってからローカル環境の実行以外にも嬉しいアップデートがあったのでそれに少し絡めて今回の取り組みを紹介しようと思います。 今回の取り組みは、モノレポで使っている Python の最低バージョンを 3.9 から 3.11 に上げるというものです。なぜ、バージョンを上げたのか、上げる際の障壁とその対応を紹介しようと思います。 はじめに なぜ Python バージョンを上げたのか パッケージ更新を頻繁にする理由 パッケージの更新ができなくなった torchserve と各ソフトウェアのバージョン Python のバージョンをどこまで上げるか torchserve のコンテナイメージを自分
npm workspacesとモノレポ探検記
❯❯❯ npx envinfo --binaries Binaries: Node: 16.13.2 - /private/var/tmp/fnm_multishells/5279_1643694868908/bin/node Yarn: 1.22.15 - ~/.local/share/npm/bin/yarn npm: 8.1.2 - /private/var/tmp/fnm_multishells/5279_1643694868908/bin/npm Watchman: 2022.01.24.00 - /usr/local/bin/watchman 用語 レポ(repo) Gitのリポジトリ。 シングルレポ(single repo) ベーシックなレポ。typescriptやeslintなどの開発ツールの設定もひとつだけで管理がかんたん。ただし、レポに対応するNPMパッケージは1個だけ
今思えばすごく簡単な話でしたが、monorepo を実現する最小構成が分からなくてちょっとつまづいたのでメモです。 そもそも monorepo 用の設定はいるのか？ amplify は標準で monorepo 用のサポートや機能が存在しています。 ユーザーからしてみれば、root の package.json から 各 workspace への alias を貼っておき、root から見たデプロイフォルダを指定さえできれば困らないはずで特にサポートは不要かにも思えます。 しかしそうしなくても amplify が提供している monorepo サポートを使えば、その package に定義された npm scripts をそのまま呼び出せたりと何かと便利なので使っていきます。 最小構成 version: 1 applications: - appRoot: packages/hoge fro
モノレポでreviewdog/action-tflintを実行するためにOSSコントリビュートして解決した - spacelyのブログ
インフラエンジニアの thaim です。 スペースリーではインフラの構築にTerraformを、Terraformのコードに対する静的解析にtflintを利用しています。 このtflintを上手く活用するために取り組んだこと、OSSコントリビュートに取り組んだことについて紹介します。 スペースリーにおけるインフラ開発の背景 始めにスペースリーのインフラ開発におけるtflintの活用状況について紹介します。 tflintを実行する Terraformのコードの静的解析ツールはいろいろと存在しますが、lintツールとしてtflintがあります。tflintはTerraformコードのコード規約を設定したり、terraform applyコマンドを実行できない不正な設定を検出したりできます。 スペースリーではTerraformコードの静的解析ツールとして terraform fmt (インデント
Poetry の Dependency Group を利用したモノレポ Python 環境｜Tatsuya Shirakawa
こんにちは、カウシェで ML Engineer をしている白川です。 以前に一人目 ML Engineer としての入社エントリーを書かせていただいたのですが、実はアプリケーションで Python を使用する開発者としても一人目だったので、機械学習系の機能開発をしつつ Python 環境の設計・構築も行っています。開拓するのは楽しいです。 今回、Poetry の dependency group 機能を使うことでモノレポにおいて軽量でクリーンに動作する、なかなかよい開発環境を作ることができたので、思い切って公開してみます！ なお、本格的な運用はこれから始めるところなので、気持ちのこもった速報版くらいの気持ちで受け取っていただけるとありがたいです。 Poetry の dependency group 便利ですよ！ モノレポカウシェは基本的にはモノレポで開発をしています。そのため、何か開発する
CircleCI™において、モノレポ構成のリポジトリで必要なテストのみ実行する方法 - BOOK☆WALKER inside
こんにちは。 メディアサービス開発部 Webアプリケーション開発課のフサギコ(髙﨑)です。 Ruby on Railsによるバックエンドの実装運用と、AWSによるサービスインフラの設計構築を中心とした、いわゆるバックエンド方面のテックリードとして働いています。 最近はNext.jsで書かれた運用者向けの管理画面までも自分たちで改修するようになってきました。 本記事ではCircleCIにおいて、モノレポ構成のリポジトリで必要なテストのみ実行するようなconfigファイルの書き方についてお話します。 モノレポ構成のリポジトリでは必要なテストだけを実行したい 複数のソフトウェアが相互に連携して動くようなプロダクトではしばしば、一つのリポジトリをディレクトリ分けしてそれぞれのソフトウェアを配置するモノレポ構成が採られます。 モノレポ構成のリポジトリでは多くの場合、複数のソフトウェアが同時に変更され
GitHub モノレポを AWS CodePipeline と統合して、プロジェクト固有の CI/CD パイプラインを実行する | Amazon Web Services
Amazon Web Services ブログ GitHub モノレポを AWS CodePipeline と統合して、プロジェクト固有の CI/CD パイプラインを実行する (この記事は、Integrate GitHub monorepo with AWS CodePipeline to run project-specific CI/CD pipelines を翻訳したものです。) AWS CodePipeline は、ソフトウェアのリリースに必要なステップをモデル化、可視化、自動化できる継続的デリバリーサービスです。AWS CodePipeline を使用して、コードを構築し、稼働前の環境にデプロイし、アプリケーションをテストし、実稼働環境にリリースするまでの完全なリリースプロセスをモデル化できます。AWS CodePipeline は、コードが変更されるたびに定義されるワークフロー
Atlantis とは Atlantisをご存じでしょうか。 簡単に言うと GitHubやGitLabなどでterraform を管理する際、自動で terraform plan 結果を表示してくれたり、 リポジトリ内で terraform apply まで行ってくれるツールで、terraform 作業をgit repositoryで完結させれるようになるツールです。 ただ、何も考えずに利用すると、 リポジトリのtopで terraform plan などと実行するため、ディレクトリに分割して管理していると辛い面があります。 そこで他の CIツールのように .atlantis.yaml というファイルを置いておくと、動作をある程度指定できるようになります。 version: 3 automerge: true projects: - name: my-project-name dir: .
こんにちは、スタメンエンジニアの手嶋です。普段はRuby on RailsやReactなどの技術を用いて開発しています。最近はフィーチャーチーム体制に切り替わったこともあり、AWSなどの技術にも触れる機会が増えました。 これまで複数のプロジェクトにおいてReact(TypeScript)で開発を行ってきました。そんな中でやはり型の恩恵を感じることが多かったのですが、バックエンドも含めてTypeScriptでアプリケーションを作成してみたいという想いが湧いてきたので、個人開発としてNext.jsとNestJSで構築したアプリケーションをモノレポで運用し本番環境で動かしてみました。 モノレポはその名の通り、単一のリポジトリ(git等)で複数のプロジェクトを管理することです。 主に以下のようなメリットを享受できないかと思い、モノレポを採用しました。 ESLint / Prettierなどの設定を
モノレポ管理ツール単体を管理するGitHubリポジトリとしてみると Lerna Bazel Nx あたりのStar数の多さが目を引きます。 ※npm Workspaces, pnpm Workspaces, Rush, Turborepo, Yarn WorkspacesのGitHub Star数はモノレポ管理以外の機能も含まれるリポジトリのためご参考 Trends比較 今回各ツールのトレンドを比較するため GitHub Star History npm trends State of JavaScript の調査を行いました。 GitHub Star History GitHub Star Historyで各GitHubリポジトリのStar数推移をチェックしてみました。 引用：GitHub Star History | bazel vs bolt vs lerna vs moon vs
[Terraform] CodeCommitで管理するモノレポの変更に応じてCodePipelineの実行を振り分ける - Qiita
はじめに 本記事では、CodeCommitで管理する単一リポジトリ（モノレポ）において、 変更されたディレクトリに応じて、実行するCodePipelineを振り分けるCIパイプラインをTerraformで構築する方法について記載しています。 Terraform で構築する全体構成図 構成の概要 Systems Managerの Parameter Storeには、リポジトリ内のディレクトリ名と実行する CodePipeline名がJSON形式で格納されています。 開発者がCodeCommit のリポジトリにコードをプッシュすると EventBridgeがリポジトリの変更イベントを検知してLambda関数をトリガー実行します。 Lambda関数は、Systems Managerのパラメータを読み取って、変更があったディレクトリに応じたCodePipeline を実行します。 変更があったディ
![[Terraform] CodeCommitで管理するモノレポの変更に応じてCodePipelineの実行を振り分ける - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5f0a2467e855aede439f2a92b2cf361396edbd34/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCVGVycmFmb3JtJTVEJTIwQ29kZUNvbW1pdCVFMyU4MSVBNyVFNyVBRSVBMSVFNyU5MCU4NiVFMyU4MSU5OSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQyVFMyU4MyU5RCVFMyU4MSVBRSVFNSVBNCU4OSVFNiU5QiVCNCVFMyU4MSVBQiVFNSVCRiU5QyVFMyU4MSU5OCVFMyU4MSVBNkNvZGVQaXBlbGluZSVFMyU4MSVBRSVFNSVBRSU5RiVFOCVBMSU4QyVFMyU4MiU5MiVFNiU4QyVBRiVFMyU4MiU4QSVFNSU4OCU4NiVFMyU4MSU5MSVFMyU4MiU4QiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MzQzOGNkZDY4NDFhOGFkZTIwMDM0ZGZjYTA3NDEwNzc%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwb2t1Ym90NTUmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zMiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTI5ZWU2N2RmYjZhZTcyOTM5Mzg1NTAxZGRiODQzZDE4%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D363ff9f7e9a619e0438020078659d5b6)
モノレポ？いらんでしょ - kk-web
と、ちょっと挑発的なタイトルにしてみましたが、いかがでしょうか。 今までモノレポに対する話題を上げることは避けていたのですが。 今回はモノレポに対する、個人的な意見をだらだらーっと書いていこうと思います。 先に結論から書いてしまうと。 タイトルの通り、個人的にはどちらかといえばモノレポ反対派です。 とはいえあたりまえですがケースバイケースだと思っていて。 もちろん有用なケースもあると思いますので、全面的に導入を反対する気は毛頭ないです。 ただメリットをデメリットが上回るケースで導入するのはアホだよね、と個人的には思っています。 あと、日本ではなぜかやたらとモノレポを持ち上げる記事が目につく一方、デメリットについてしっかりと触れられている記事が少ないなと思います、あくまで個人的にですが。 まず、モノレポを導入することによって得られるメリットって以下のような感じかなーと思います。 複数のリポジ
モノレポとマイクロサービス - Qiita
コロナの影響で在宅勤務(テレワーク)も一ヶ月以上も続き環境の変化に慣れてきましたが、BBCパパのように急な家族の割り込みによる対応で頭を悩まされている streampack の Tana です。 (在宅疲れした際に見るとリラックスできますw) モノレポ(Monorepo)とマイクロサービスへの取り組みについて streampack は動画配信プラットフォームをお客様の要望にカスタマイズしながら、AWSなどのクラウド上に提供しているサービスです。既存のシステムとマイクロサービスを最大限に活かすために、案件ごとに管理していた複数のレポジトリ管理からモノレポへ移管したかについての経験談のお話になります。 以前は案件やレイヤー毎にリポジトリを切って開発してました。いわゆる Polyrepo(Multi-Repo) と呼ばれる方法です。 例えば、 - project1_frontend - proj
｜はじめに CAMでWebフロントエンドエンジニアをしている三好です。 今回はCAMで扱っている、FensiをプラットフォームとしたWebサービスのモノレポをマルチレポに変更したことについて、変更に至った経緯と運用してわかったメリット、デメリットをお話します。 実際にこれが正解だとは思いませんが、変更した結果どのような考えに変わっていったのかをここでは書かせていただこうと思います。 ｜モノレポ、マルチレポとは 単一のリポジトリで複数のプロジェクトを管理することをモノレポと言い、単一のリポジトリで単一のプロジェクトを管理することはマルチレポと言います。 JavaScriptのトランスコンパイラであるBabelでは、実際にモノレポでプロジェクトを管理することによって、以下のようなメリット、デメリットがあると述べられています。(参考: https://github.com/babel/babel
[アップデート]AWS App Runnerは、ソースディレクトリを指定してコマンド実行できるようになり、モノレポのデプロイに対応しました | DevelopersIO
[アップデート]AWS App Runnerは、ソースディレクトリを指定してコマンド実行できるようになり、モノレポのデプロイに対応しました はじめに App Runnerは、モノレポ構成のリポジトリのデプロイに対応しました。 モノレポとは、アプリケーションやマイクロサービスなどのコードを同一リポジトリで管理する手法のことです。 これまでは、ビルドおよび起動コマンドの実行は、リポジトリのルートディレクトリのみをサポートしていました。 今回のアップデートにより、App Runnerでは任意のソースディレクトリ（コマンドを実行するパス）を指定できるようになりました。 これにより、開発者は指定したソースディレクトリからビルドし、起動コマンドを実行できるため、モノレポ構成のリポジトリのデプロイが容易になりました。 AWSマネジメントコンソールで確認すると、「ソースディレクトリ」を指定できるようになっ
![[アップデート]AWS App Runnerは、ソースディレクトリを指定してコマンド実行できるようになり、モノレポのデプロイに対応しました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/fea11ef75ff70229697ab3ba15f47d6b9074179b/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2023%2F08%2Faws-app-runner.png)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話
TerraformモノレポCIのセキュア化 | メルカリエンジニアリング
フロントエンドのモノレポ構成はスケーリングの夢を見るか | サイボウズ フロントエンドエキスパートチーム
医療スタートアップのバックエンドをモノレポ化した話 〜戦略・プロセス編〜 - 株式会社ヘンリー エンジニアブログ
GitHub Actions でモノレポ上の変更があったプロジェクトだけテストを走らせる
モノレポのはなし / karino2 - Message Passing
モノレポにおけるback/front間のPrismaの型共有の方法
医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ
モノレポの手癖を deno で CLI ツールを作って楽にしたい
モノレポでの GitHub Actions CI の泥臭い高速化
Rustを使ってCLI(Rust)とVSCode拡張(TS+Wasm)を同時にモノレポでリリースしてみました
モノレポ好きじゃない / morrita - Message Passing
Node.jsモノレポ開発のターミナルログ混雑解消のための新作CLIツールnotiosを紹介
モノレポの Python バージョンを 3.9 から 3.11 に上げる - CADDi Tech Blog
amplify でモノレポのパッケージをデプロイする最小構成
モノレポ terraform で atlantis を活用している話 - なんかいろいろと
Next.js×NestJSをモノレポで構築/運用してみました - stmn tech blog
今モノレポやるならどのツール使うのがいいのん?? - Qiita
運用してわかった！モノレポに向いているプロジェクト | 株式会社CAM
oizen.co.jp
logmi.jp
www.stv.jp
www.nikkei.com
tver.jp
chiwawatan.hatenablog.com