検索対象

並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 73件

新着順 人気順

モノレポの検索結果1 - 40 件 / 73件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

モノレポに関するエントリは73件あります。 開発、 monorepo、 github などが関連タグです。 人気エントリには 『モノレポにすべきか、レポジトリを分割すべきか』などがあります。

モノレポの関連エントリー

  • モノレポにすべきか、レポジトリを分割すべきか

    先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように

      モノレポにすべきか、レポジトリを分割すべきか

    • モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話

      こんにちは、Sally社 CTO の @aitaro です。 マーダーミステリーアプリ「ウズ」とマダミス制作ツール「ウズスタジオ」、マダミス情報サイト「マダミス.jp」を開発しています。 はじめに この記事ではウズの開発当初から利用していた Docker Compose をやめることにした背景についてご紹介します。 Docker Compose は各マシンの開発環境での差異を吸収するというメリットがあり、多くの開発現場で導入されていますが、Docker Composeの抱えているデメリットを勘案して、最終的に一部を残して辞める決断をしました。 Docker Composeの特徴 Docker Composeは、複数のコンテナを定義し、管理するためのツールです。ウズの開発環境では、バックエンド、フロントエンド、データベースなどをそれぞれコンテナ化して、Composeで一括管理していました。こ

        モノレポの開発環境でDocker ComposeをやめてTaskfileを導入した話

      • TypeScriptのモノレポ構成を考える

        はじめにlink あまりモノレポの構成について語られている記事が多くないなと感じたので、現時点で自分が考えている設計をまとめてみる。 以前にTwitterでディレクトリ構成と内容については言及したが、実際に利用する技術についてはあまり触れなかったので改めて検証してみた。 https://twitter.com/koh110/status/1617510034266808322 クライアントサイドとサーバーサイドのコード共有については下記の記事がよくまとまっていた。 https://capelski.medium.com/effective-code-sharing-in-typescript-monorepos-475f9600f6b4 上記の記事の構成も参考にしつつ、自分の考えも加えて検証していく。 相対パスを利用する方法 npmのローカルパス指定（file:xx）を利用する方法 シンボ

          TypeScriptのモノレポ構成を考える

        • ファインディの爆速開発を支えるモノレポ管理ツール「Nx」について - Findy Tech Blog

          ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 この記事では、ファインディで導入しているモノレポ管理ツール「 Nx 」について紹介します。 モノレポとは Nxとは Nxワークスペースの作成 Nxの機能 コード生成 変更検知 依存関係の管理 キャッシュ機構 自動マイグレーション まとめ モノレポとは モノレポは全てのコードベースを単一のリポジトリで管理する手法です。 monorepo.tools コードの共通化や可視化、ツール・ライブラリの標準化、一貫性のあるCI/CDパイプラインを構築できるといったメリットがあります。また、マイクロサービスと相性が良いとも言われています。 circleci.com ファインディでは主にフロントエンド系のリポジトリをモノレポとして運用しています。 アプリケーションとそれに関連するフィーチャー、UIライブラリがひとつに

            ファインディの爆速開発を支えるモノレポ管理ツール「Nx」について - Findy Tech Blog

            • モノレポの関連エントリー

          • TerraformモノレポCIのセキュア化 | メルカリエンジニアリング

            ※本記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud Platform（GCP）であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と

              TerraformモノレポCIのセキュア化 | メルカリエンジニアリング

            • Railsのマイクロサービスアーキテクチャで構成されたアプリをモノレポ構成に移行した話 - Sansan Tech Blog

              こんにちは。技術本部Sansan Engineering Unit Master Data Groupの古本です。 普段は、営業DXサービス「Sansan」の名刺交換した人や企業に関するニュースを表示し、お知らせする「企業ニュース」や「企業情報」を扱うシステムの開発をしています。 最近、マイクロサービスで作られた企業ニュースのシステムをモノレポ構成に移行しました。 今回はその時に行ったことについて話します。 モノレポ（mono repo）とは 本ブログで類似の記事があったので引用します。 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 今回も複数レポジ

                Railsのマイクロサービスアーキテクチャで構成されたアプリをモノレポ構成に移行した話 - Sansan Tech Blog

              • フロントエンドのモノレポ構成はスケーリングの夢を見るか | サイボウズ フロントエンドエキスパートチーム

                それっぽいタイトルを付けましたが特に意味はないです。 workspace を使ったコマンドを最適化して実行する Turborepo についてのお話で Turborepo を軽く触ってみた際にnpx create-turbo@latestで作られる構成がとてもわかりやすく、プロダクトの初期段階からモノレポを採用するのは選択肢の 1 つとしていいのでは、と思い続編を書きました。 前回と同じくサンプルのリポジトリはこちらになります。 https://github.com/nus3/p-turborepo/tree/main/yarn 概要 モノレポを採用することで、同一リポジトリ内で自作した汎用的なライブラリやコンポーネントを複数のアプリケーションで使いまわせる モノレポの規模が大きくなってきた場合には、モノレポ内のパッケージを npm に公開することでアプリケーションとパッケージを非同期に開発

                  フロントエンドのモノレポ構成はスケーリングの夢を見るか | サイボウズ フロントエンドエキスパートチーム

                • モノレポ統合により複雑なマイクロサービスの開発を単純化するアプローチ — HACK The Nikkei

                  はじめに Nikkei Advent Calendar 2024 の 12 日目の記事です。 初めまして。日本経済新聞社で Web Platform Team で日経電子版 Web の技術的なプラットフォームの開発や、他チームへの技術支援を行っている 林(@Shinyaigeek) と 竹本 と申します。 今回、日経電子版の抱えていた、莫大なリポジトリ数で構成されるマイクロサービスをモノレポ化してしまうことにより、開発効率を向上させた事例についてお話しします。 背景 日経電子版 Web は垂直分割なマイクロサービス構成が取られています。 皆さんが日経電子版 Web にアクセスする際には、www.nikkei.com という単一のドメインへとアクセスしていますが、そのアクセスは最初 Fastly で受け取っています。 そして Fastly が Reverse Proxy 層として振る舞ってお

                    モノレポ統合により複雑なマイクロサービスの開発を単純化するアプローチ — HACK The Nikkei

                  • 散らばった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もバ

                      散らばったAWS LambdaのGitHubリポジトリをモノレポ構成にしてメンテナンスコストを削減する - クラウドワークス エンジニアブログ

                    • 医療スタートアップのバックエンドをモノレポ化した話 〜戦略・プロセス編〜 - 株式会社ヘンリー エンジニアブログ

                      こんにちは、ヘンリーの 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 ではディレクトリのルートレベルに、各パッケージを管理する

                          Bun workspace で始めるモノレポ生活

                        • [TypeScript]モノレポ管理ツール比較検討

                          モノレポ管理のツールを検討したときのメモ Background 自分が所属するチームで開発する JavaScript/TypeScript のプロダクトが増えてきて、同じような内容のリポジトリがいくつも存在している（n個とする）。 変更を加えていくにつれて、それぞれの差分が大きくなり、以下のような問題が発生する。 開発が止まっているプロジェクトの構成が古くなり、修正コストが発生する 開発が複数同時進行している場合、同じような実装を手動で同期する必要がある これらは共通の基盤等があれば効率的に（理想的にはn分の1の労力で）開発が可能であり、将来的なコストを考えると、いまのうちにその仕組みを考えておきたい。 Proposed Solutions 要件は以下 複数のパッケージをnpmとしてpublishできる アプリケーションも管理できる Nx, Rush, Lerna を主要な選択肢としている

                            [TypeScript]モノレポ管理ツール比較検討

                          • GitHub Actions でモノレポ上の変更があったプロジェクトだけテストを走らせる

                            重要な追記 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}

                              GitHub Actions でモノレポ上の変更があったプロジェクトだけテストを走らせる

                            • タスク数100超え！モノレポとエスプレスタックで支えるECS管理の仕組み（ecspresso/ecschedule） - ウェルスナビ開発者ブログ

                              ECSの運用で発生した悩み リポジトリ分割と採用ツール 採用したツール モノレポ管理 jsonnetの利用イメージ パイプラインの実装 差分検出 反映の高速化 crontabのJST表記対応 ecspresso verifyによるチェック OPAによるポリシーチェック さいごに こんにちは、インフラエンジニアの和田です。 弊社は、WEBアプリケーションおよびバッチ処理の実行基盤として Amazon Elastic Container Service（以下「ECS」と呼ぶ） を採用しています。現在では複数チームの開発者が 100 を超えるタスク定義を運用する規模にまで拡大しています。この記事では、増え続けるECS定義をモノレポとエスプレスタック（ecspresso/ecschedule）で管理した事例を紹介します。 ECSの運用で発生した悩み ECSを利用する開発者やアプリケーション数が増え

                                タスク数100超え！モノレポとエスプレスタックで支えるECS管理の仕組み（ecspresso/ecschedule） - ウェルスナビ開発者ブログ

                              • モノレポのはなし / karino2 - Message Passing

                                モノレポについて経験豊富そうな皆さんの話を聞きたい。 まずはその背景から。 会社で分かれるレポジトリ フリーランスをやっていると、たまにいろんな零細企業を集めて一つのサービスを作る場に遭遇する。 人を集める時に、一つの会社だけじゃなくて複数の会社が集まることがよくある。 たとえばマーケティングが強みの会社が自社ではエンジニアを持っていなくて、開発は外部の人たちを集めてやるみたいな。 しかもそれぞれの会社からは一人とか二人だけしか来ないので、 6人の小規模なチームなのに会社は4つあるとかいう状況になったりもする。 そうすると何が起こるかというと、レポジトリが会社ごとに分かれたりする。 「クラウドとフロントの間はAPIを決めましょう、 それでクラウド側がバイナリをリリースして、フロント側がたまにそれをマージしましょう」みたいなフローになる。フロントとバックエンドなんて関わっているのは3人しか居

                                  モノレポのはなし / karino2 - Message Passing

                                • 巨大モノレポのKubernetes移行プロジェクト：食べログの実践的アプローチ - Tabelog Tech Blog

                                  目次 1章 はじめに 2章 食べログのKubernetes移行について Kubernetes移行の背景 これまでの歩み 3章 巨大モノレポのKubernetes移行におけるチームの課題 現状 課題 解決: 「俺に任せろ」 4章 巨大モノレポのKubernetes移行を始める戦略 戦略1: 一度にたくさんのことをしようとしない 戦略2: リフトアンドシフト 戦略3: 切り替えは迅速かつシームレスに 5章 巨大モノレポのKubernetes移行の実践 「Webサーバ設定を可能なかぎりそのまま維持」のためのconfigを揃える ユーザ影響がわかるようにモニタリング整備 切り替え 6章 おわりに モノレポのWebサーバ Kubernetes移行は完了、次はAPサーバ Kubernetesについて深く理解しておくのが大事 Webサーバだけを移行対象にしたのはかなり良かった やってよかったKubern

                                    巨大モノレポのKubernetes移行プロジェクト：食べログの実践的アプローチ - Tabelog Tech Blog

                                  • モノレポにおけるback/front間のPrismaの型共有の方法

                                    詳しい方いたら教えてください。めっちゃ欲しい情報ですん。 別にモノレポでなくてもいいんですが、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

                                      モノレポにおけるback/front間のPrismaの型共有の方法

                                    • モノレポでマージキューと必須ステータスチェックを運用するためのTips - ROUTE06 Tech Blog

                                      ROUTE06 でソフトウェアエンジニアをしている @MH4GF です。 GitHub のマージキュー(Merge Queue)を私のチームでの開発フローに取り入れてから数ヶ月経ちました。マージキューは非常に便利ですが、挙動の理解やセットアップに難しさがあると感じています。いくつかの課題の対処ができ安定した運用ができてきたので、この記事ではセットアップでつまづきがちな点を紹介します。 マージキューとは マージキューは 2023 年 7 月に一般公開された比較的新しい機能で、簡単に説明すると「プルリクエストのマージ前にマージ先ブランチを取り込んだ上で CI を実行し、通ることを確認してからマージする」機能です。 複数人で GitHub を利用した開発をしていると、main ブランチの取り込み漏れにより「プルリクエストでの CI は通るものの、マージ後の main ブランチの CI は失敗する

                                        モノレポでマージキューと必須ステータスチェックを運用するためのTips - ROUTE06 Tech Blog

                                      • マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog

                                        Sansan Engineering UnitでSansan Data Hubの開発をしている藤原です。 前回はニッチに深く潜り過ぎたので、今回は（使い古されたネタではありますが）モノレポ化についてお話ししたいと思います。 おさらい：モノレポ（mono repo）とは 一連のソースコードを単一のリポジトリで管理している状態のことです。 特に、実装言語、またはサブシステムやドメインといった何らかの区切りでリポジトリを分けている場合に、それらを集約することをモノレポ化と言います。 逆に、複数のリポジトリに分けている状態をポリレポ（poly repo）と言います。 モノレポのメリットとデメリット モノレポ化することで、以下のようなメリットが得られます。 プロダクト全体で統一したい設定、たとえばCIスクリプトやlinter設定などの管理が楽になる。 検索が楽になる。GitHubの検索で事足りること

                                          マイクロサービスアーキテクチャのリポジトリ構成を漸進的にモノレポに移行した話 - Sansan Tech Blog

                                        • 医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ

                                          こんにちは、ヘンリーの 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 - LIVESENSE ENGINEER BLOG

                                            • モノレポの手癖を deno で CLI ツールを作って楽にしたい

                                              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": "

                                                モノレポの手癖を deno で CLI ツールを作って楽にしたい

                                              • モノレポでの GitHub Actions CI の泥臭い高速化

                                                はじめに みなさんこんにちは、物流業界の価値最大化をミッションに掲げ運送会社のDXに寄り添うアセンド株式会社でCTOを務めている丹羽です。 1日5.2回のリリースを実現するプロダクトチームの開発体験を支えるCIの高速化についてご紹介します（先週3/20週の平均値）。1日に数回デプロイというレベルでの素早く開発するにおいて、 push 時の CI Check の速さは地味ですが開発体験にとって見逃せない存在になります。特にモノレポ環境ではジョブが複数ある中でいかに省略ができるかが鍵となり、泥臭くも数十秒でも高速化のため戦ったポイントを紹介します。 アセンドでは顧客課題を中心にプロダクト開発をするためにフルサイクルエンジニアという開発スタイルを取り、１エンジニアがフロント・バックエンドだけでなく設計からリリース・サポートまでのソフトウェアのライフサイクル全体にオーナーシップを持って開発していま

                                                  モノレポでの GitHub Actions CI の泥臭い高速化

                                                • Rustを使ってCLI(Rust)とVSCodeæ‹¡å¼µ(TS+Wasm)を同時にモノレポでリリースしてみました

                                                  Rustを使ってCLIとVSCode拡張を同時に作ってみたよという記事です！ ここで言う「同時に作った」とは「CLIとVSCode拡張に共通するコアの処理をRustで実装し、CLIはコア処理以外もRustで実装する一方、vscode拡張はTSベースで実装してコア処理はWasmに変換して呼び出す実装にした」という意味です。 それをモノレポでやってみて、けっこう色々いい感じだった＆勉強になったので記録を残しておいてみます👶 なお、ツールのアイデアをくれたtaisaさん、Wasmを使うアイデアをくれたyokoishiさん本当にありがとうございました！ 作ったもの MySQLのINSERTクエリをテーブルのような見た目に、つまりカラム名と各行の値がタテ方向に並んで見えるようフォーマットするというものです。 自分の勤め先ではテストデータを大量のINSERTクエリで表現する場面がしばしばあり、地味な

                                                    Rustを使ってCLI(Rust)とVSCode拡張(TS+Wasm)を同時にモノレポでリリースしてみました

                                                  • モノレポ好きじゃない / morrita - Message Passing

                                                    自分は今は社内 Monorepo での作業がメインで、たまに Android とかさわってる。 レポジトリの壁というか、レポジトリの違いを含むインフラの違いの壁は、組織の壁より厚い。 この話は前にも書いたことがある。 だから向井さんの言っていることはよくわかる。 Monorepo が強制するインフラ共通化が押し下げた組織の壁の低さを、しばしば実感する。 たとえば最近だと、仕事でやっている Android アプリの APK のビルド方法が変わった際にビルドツールチェインにあるマイナーなバグにあたってしまい、 そのツールのバグを直したことがあった。そんなツールがあるとは知らなかったというくらい降って湧いた話。 でもビルドシステムが統一されているおかげでコードをビルドするのもテストするのも簡単で、 IDE も普段の設定そのまま。コードレビューもいつもと同じ。 はじめてのコードベース、レビュー相手

                                                      モノレポ好きじゃない / morrita - Message Passing

                                                    • サービス成長と共に肥大化するモノレポ、長くなるCI時間 / As services grow, monorepos get bigger and CI time gets longer

                                                      SRE観点での技術負債 懺悔会 2024 https://mixi.connpass.com/event/312191/

                                                        サービス成長と共に肥大化するモノレポ、長くなるCI時間 / As services grow, monorepos get bigger and CI time gets longer

                                                      • Node.jsモノレポ開発のターミナルログ混雑解消のための新作CLIツールnotiosを紹介

                                                        こんにちは。フルーリオ株式会社の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 経由で起動していない場合は

                                                          Node.jsモノレポ開発のターミナルログ混雑解消のための新作CLIツールnotiosを紹介

                                                        • pnpm 9.5 でリリースされた Catalogs 機能を使ってモノレポ内の依存パッケージのバージョンを揃える

                                                          Catalogs を使うモチベーション Catalogs のメリットについては、ドキュメントではざっくり以下の3点が挙げられています。 単一バージョンを維持できることで、パッケージの重複によるバグの発生を防ぐ pnpm-workspace.yml を編集するだけで依存関係のアップグレードが完了する 依存関係アップグレード時に package.json を編集しなくてよくなり、git でのコンフリクトを避けられる 筆者の環境では特に1つ目の、「パッケージの重複によるバグを防ぐ」というのが大きなモチベーションとなりました。 モノレポと共通パッケージとパッケージ重複 筆者の環境では一部の Web Frontend もモノレポで運用しており、そのなかで一部の共通実装はモノレポ内パッケージとして切り出されています。以下は架空の例ですが、おおまかにこのような構造となっています。 たとえば各 webap

                                                            pnpm 9.5 でリリースされた Catalogs 機能を使ってモノレポ内の依存パッケージのバージョンを揃える

                                                          • 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個だけ

                                                              npm workspacesとモノレポ探検記

                                                            • 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とは？ 素早さ 分かりやすさ 管理のしやすさ その

                                                                3ヶ月で120のリポジトリを1つのMonorepo(モノレポ/モノリポ)に移行した話 - asoview! Tech Blog

                                                              • モノレポの Python バージョンを 3.9 から 3.11 に上げる - CADDi Tech Blog

                                                                はじめに AI Team MLOps Engineer の西原です。前回は kubeflow pipeline(kfp)のローカル環境での実行について Tech Blog を書きました。kfp は 2024 年に入ってからローカル環境の実行以外にも嬉しいアップデートがあったのでそれに少し絡めて今回の取り組みを紹介しようと思います。 今回の取り組みは、モノレポで使っている Python の最低バージョンを 3.9 から 3.11 に上げるというものです。なぜ、バージョンを上げたのか、上げる際の障壁とその対応を紹介しようと思います。 はじめに なぜ Python バージョンを上げたのか パッケージ更新を頻繁にする理由 パッケージの更新ができなくなった torchserve と各ソフトウェアのバージョン Python のバージョンをどこまで上げるか torchserve のコンテナイメージを自分

                                                                  モノレポの Python バージョンを 3.9 から 3.11 に上げる - CADDi Tech Blog

                                                                • amplify でモノレポのパッケージをデプロイする最小構成

                                                                  今思えばすごく簡単な話でしたが、monorepo を実現する最小構成が分からなくてちょっとつまづいたのでメモです。 そもそも monorepo 用の設定はいるのか？ amplify は標準で monorepo 用のサポートや機能が存在しています。 ユーザーからしてみれば、root の package.json から 各 workspace への alias を貼っておき、root から見たデプロイフォルダを指定さえできれば困らないはずで特にサポートは不要かにも思えます。 しかしそうしなくても amplify が提供している monorepo サポートを使えば、その package に定義された npm scripts をそのまま呼び出せたりと何かと便利なので使っていきます。 最小構成 version: 1 applications: - appRoot: packages/hoge fro

                                                                    amplify でモノレポのパッケージをデプロイする最小構成

                                                                  • モノレポでreviewdog/action-tflintを実行するためにOSSコントリビュートして解決した - spacelyのブログ

                                                                    インフラエンジニアの thaim です。 スペースリーではインフラの構築にTerraformを、Terraformのコードに対する静的解析にtflintを利用しています。 このtflintを上手く活用するために取り組んだこと、OSSコントリビュートに取り組んだことについて紹介します。 スペースリーにおけるインフラ開発の背景 始めにスペースリーのインフラ開発におけるtflintの活用状況について紹介します。 tflintを実行する Terraformのコードの静的解析ツールはいろいろと存在しますが、lintツールとしてtflintがあります。tflintはTerraformコードのコード規約を設定したり、terraform applyコマンドを実行できない不正な設定を検出したりできます。 スペースリーではTerraformコードの静的解析ツールとして terraform fmt (インデント

                                                                      モノレポでreviewdog/action-tflintを実行するためにOSSコントリビュートして解決した - spacelyのブログ

                                                                    • Nx活用術！モノレポ内のStorybookのパス設定自動化 - Findy Tech Blog

                                                                      ファインディ株式会社でフロントエンドのリードをしている新福(@puku0x)です。 この記事はFindy Advent Calendar 2024 4日目の記事です。 adventar.org Nxはモノレポ管理の便利なユーティリティとして @nx/devkit を提供しています。 今回は @nx/devkit を利用したStorybookの設定の自動化についてご紹介します。 Nxについては以前の記事で紹介しておりますので、気になる方は是非ご覧ください。 tech.findy.co.jp モノレポでStorybookをどのように管理するか？ どうやってパス設定を自動化するか？ 実装してみよう！ まとめ モノレポでStorybookをどのように管理するか？ 皆さんはモノレポでStorybookを運用されたことはありますでしょうか？ 概ねどちらかの方法を採用することになるかと思います。 単一の

                                                                        Nx活用術！モノレポ内のStorybookのパス設定自動化 - Findy Tech Blog

                                                                      • Poetry の Dependency Group を利用したモノレポ Python 環境｜Tatsuya Shirakawa

                                                                        こんにちは、カウシェで ML Engineer をしている白川です。 以前に一人目 ML Engineer としての入社エントリーを書かせていただいたのですが、実はアプリケーションで Python を使用する開発者としても一人目だったので、機械学習系の機能開発をしつつ Python 環境の設計・構築も行っています。開拓するのは楽しいです。 今回、Poetry の dependency group 機能を使うことでモノレポにおいて軽量でクリーンに動作する、なかなかよい開発環境を作ることができたので、思い切って公開してみます！ なお、本格的な運用はこれから始めるところなので、気持ちのこもった速報版くらいの気持ちで受け取っていただけるとありがたいです。 Poetry の dependency group 便利ですよ！ モノレポカウシェは基本的にはモノレポで開発をしています。そのため、何か開発する

                                                                          Poetry の Dependency Group を利用したモノレポ Python 環境｜Tatsuya Shirakawa

                                                                        • CircleCI™において、モノレポ構成のリポジトリで必要なテストのみ実行する方法 - BOOK☆WALKER inside

                                                                          こんにちは。 メディアサービス開発部 Webアプリケーション開発課のフサギコ(髙﨑)です。 Ruby on Railsによるバックエンドの実装運用と、AWSによるサービスインフラの設計構築を中心とした、いわゆるバックエンド方面のテックリードとして働いています。 最近はNext.jsで書かれた運用者向けの管理画面までも自分たちで改修するようになってきました。 本記事ではCircleCIにおいて、モノレポ構成のリポジトリで必要なテストのみ実行するようなconfigファイルの書き方についてお話します。 モノレポ構成のリポジトリでは必要なテストだけを実行したい 複数のソフトウェアが相互に連携して動くようなプロダクトではしばしば、一つのリポジトリをディレクトリ分けしてそれぞれのソフトウェアを配置するモノレポ構成が採られます。 モノレポ構成のリポジトリでは多くの場合、複数のソフトウェアが同時に変更され

                                                                            CircleCI™において、モノレポ構成のリポジトリで必要なテストのみ実行する方法 - BOOK☆WALKER inside

                                                                          • 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 は、コードが変更されるたびに定義されるワークフロー

                                                                              GitHub モノレポを AWS CodePipeline と統合して、プロジェクト固有の CI/CD パイプラインを実行する | Amazon Web Services

                                                                            • Next.js×NestJSをモノレポで構築/運用してみました - stmn tech blog

                                                                              こんにちは、スタメンエンジニアの手嶋です。普段はRuby on RailsやReactなどの技術を用いて開発しています。最近はフィーチャーチーム体制に切り替わったこともあり、AWSなどの技術にも触れる機会が増えました。 これまで複数のプロジェクトにおいてReact(TypeScript)で開発を行ってきました。そんな中でやはり型の恩恵を感じることが多かったのですが、バックエンドも含めてTypeScriptでアプリケーションを作成してみたいという想いが湧いてきたので、個人開発としてNext.jsとNestJSで構築したアプリケーションをモノレポで運用し本番環境で動かしてみました。 モノレポはその名の通り、単一のリポジトリ(git等)で複数のプロジェクトを管理することです。 主に以下のようなメリットを享受できないかと思い、モノレポを採用しました。 ESLint / Prettierなどの設定を

                                                                                Next.js×NestJSをモノレポで構築/運用してみました - stmn tech blog

                                                                              • 今モノレポやるならどのツール使うのがいいのん?? - Qiita

                                                                                モノレポ管理ツール単体を管理する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

                                                                                  今モノレポやるならどのツール使うのがいいのん?? - Qiita

                                                                                • モノレポ管理ツールを Nx から Turborepo へ移行した話 - DeLMO（identify）エンジニアブログ

                                                                                  これは何 今回モノレポ管理ツールを Nx から Turborepo へと移行したのですが、ポリレポからモノレポへの移行に関する記事はあっても管理ツールのリプレイスというのはあまり見当たらなかったため、その知見を共有したいと思います。 弊社サービスとフロントエンドの構成について identify株式会社で副業エンジニアとして主にフロントエンドをお手伝いしている @uekenu です。 弊社identify株式会社では動画素材サービスDeLMOの運営を行っています。DeLMOは動画をダウンロードする広告主様/代理店様と動画提供者のクリエイターに利用いただいており、そこに特権管理者である弊社のスタッフを加えるとユーザーの属性としては3種類に分けることができます。そして3種のユーザーにそれぞれ別々の環境の画面を用意しています。 アーキテクチャとしては、バックエンドに GraphQL サーバーがあり

                                                                                    モノレポ管理ツールを Nx から Turborepo へ移行した話 - DeLMO（identify）エンジニアブログ
                                                                                  1 2 次のページ

                                                                                  新着記事

                                                                                  はてなブックマーク

                                                                                  公式Twitter

                                                                                  はてなのサービス

                                                                                  • App Storeからダウンロード
                                                                                  • Google Playで手に入れよう
                                                                                  Copyright © 2005-2024 Hatena. All Rights Reserved.