Monorepo Explained
Everything you need to know about monorepos, and the tools to build them.- Made with love by Nrwl (the company behind Nx) Understanding Monorepos Monorepos are hot right now, especially among Web developers. We created this resource to help developers understand what monorepos are, what benefitsthey can bring, and the tools available to make monorepo development delightful. There are many great mo
Poetry の Dependency Group を利用したモノレポ Python 環境｜Tatsuya Shirakawa
こんにちは、カウシェで ML Engineer をしている白川です。 以前に一人目 ML Engineer としての入社エントリーを書かせていただいたのですが、実はアプリケーションで Python を使用する開発者としても一人目だったので、機械学習系の機能開発をしつつ Python 環境の設計・構築も行っています。開拓するのは楽しいです。 今回、Poetry の dependency group 機能を使うことでモノレポにおいて軽量でクリーンに動作する、なかなかよい開発環境を作ることができたので、思い切って公開してみます！ なお、本格的な運用はこれから始めるところなので、気持ちのこもった速報版くらいの気持ちで受け取っていただけるとありがたいです。 Poetry の dependency group 便利ですよ！ モノレポカウシェは基本的にはモノレポで開発をしています。そのため、何か開発する
GitHub - newren/git-filter-repo: Quickly rewrite git repository history (filter-branch replacement)
git filter-repo is a versatile tool for rewriting history, which includes capabilities I have not found anywhere else. It roughly falls into the same space of tool as git filter-branch but without the capitulation-inducing poor performance, with far more capabilities, and with a design that scales usability-wise beyond trivial rewriting cases. git filter-repo is now recommended by the git project
医療系スタートアップのバックエンドをモノレポ化した話 〜技術編〜 - 株式会社ヘンリー エンジニアブログ
こんにちは、ヘンリーの SRE の戸田と Wildcard Engineer の岩永です。 弊社ではレセコン一体型クラウド電子カルテの Henry を開発・提供しています。 前編の Henry のバックエンドをモノレポ化した戦略やプロセスに続いて、後編のこちらの記事ではモノレポ化の技術的手法を解説します。 dev.henry.jp 実際のモノレポ化の流れに沿って、ポイントを3点説明します。 2つの git リポジトリのマージ アプリケーション・ワークフローのモノレポ対応 モノレポへの切り替え当日に向けた手順書の作成 1. 2つの git リポジトリのマージ 今回のモノレポ化においては、もともと存在していた henry-general-api と henry-receipt-api という2つのマイクロサービスのリポジトリを、1つのリポジトリにマージし、それぞれのマイクロサービスがサブディレ
トランクベース開発について - 赤帽エンジニアブログ
こんにちは、Red Hatでソリューションアーキテクトをしている石川です。 最近色々なカンファレンスやWebの記事などでトランクベース開発について目にする機会が増えてきました。 トランクベース開発とは、一言で言えばGitを使った開発におけるブランチ戦略の一種です。Gitのブランチ戦略というと有名なものであれば、Git FlowやGitHub Flowなどがありますが、トランクベース開発は、CICDと組み合わせた開発の効率化や高頻度のデプロイという点で昨今注目を集めています。 本記事ではそんなトランクベース開発についてご紹介したいと思います。 そもそもなぜブランチ戦略が必要か？ トランクベース開発の説明をする前に、そもそもブランチ戦略とは何かについて考えてみましょう。 例えば、一人で個人的なプロジェクトに取り組む場合、Gitで複数のブランチを使う動機はほぼ無いでしょう。アプリケーションを開発
フロントエンドの Monorepo をやめてリポジトリ分割したワケ - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシのプロダクトは、管理者の方が使う Web アプリに React、現場の方が使う iPad / iPhone アプリに React Native を採用しています。 どちらもフロントエンドの技術スタックを採用していることもあり、先日までは Monorepo と Yarn Workspaces の構成で運用されていました。 最近では Monorepo 化を進めている事例もよく見かけるようになってきました。 engineering.mercari.com devblog.thebase.in ですが、カミナシでは Monorepo をやめてリポジトリ分割をする意思決定を行いました。 具体的には、harami_client という Monorepo を harami_web と harami_mobile とい
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
git statusが43秒かかっていたのを1秒に高速化する大規模Gitリポジトリの操作を高速化するためのscalarを紹介 | Act as Professional
Git 2.38がリリースされました。 このバージョンから大規模Gitリポジトリの操作を高速化するscalarが同梱されるようになりました。 今回はこのscalarによって、どれぐらいGitの操作が高速化されるのかを簡単に検証します。 結論から言うとgit statusが約43秒かかっていたのが約1秒で操作できるようになります。 Install Git 2.38Git 2.38からscalarが同梱されましたので、各自の環境にあわせてInstallなりVersionUpなりをしてください。 $ git --version git version 2.38.0 Before大規模Gitリポジトリとしてchromiumを利用しました。 普通にgit cloneしてきて、git statusを実施すると約37秒かかります。 ❯ time git status On branch main You
モノレポなClojureプロジェクトをClojure LSPで開発するための設定方法 - Toyokumo Tech Blog
こんにちは。開発本部の木下です。 Visual Studio Codeの普及と同じくしてLSP(Language Server Protocol)を開発で使用することは普通のこととして浸透したように思います。 LSP があれば、Intellij IDEAに代表される IDE が提供してきたような開発体験を VSCode や Vim や Emacs といった普段から自分が使用しているエディタで得られることができるようになります。 しかしながら弊社の Clojure アプリケーションで LSP を使った開発を生産的に行うには 1 つ問題がありました。 この記事ではどういった問題なのかということと、その解決策について記載します。 これまでの構成 LSP で開発するときの問題点 解決策 1: LSP のための deps.edn を用意する 解決策 2: 1 つのモジュールにまとめる 2.1 ソース
30近いリポジトリを一つのリポジトリにまとめました - HRBrain Blog
こんにちは！HRBrainプラットフォームチームの桜庭です。 この度HRBrainでは、アプリケーションごとにリポジトリを持つ形式から複数のアプリケーションを1つのリポジトリにまとめる形式(以下モノレポ)へ移行しました。 この記事ではいかにしてモノれぽに移行したのかを書いていきます。 アプリケーションやチームの規模その他諸々の事情によって良し悪しは変わってるのでこの記事ではモノレポとPolyrepoの比較については書きません。 どうして移行するのか HRBrainではマイクロサービスアーキテクチャを採用しています。 そのため、提供しているそれぞれのサービス(人事評価、社員名簿、組織図、組織分析)や認証基盤などのフロントエンドとバックエンドを別なリポジトリで管理していました。 最初はそれでうまく回っていましたが、最近では以下のような問題が発生するようになりました。 他のリポジトリにある共通処
マイクロサービスのローカル開発をTiltでちょっと楽にする - HRBrain Blog
こんにちは、バックエンドエンジニアの鈴木(善)です。 昨年に引き続き、今年もHRBrainではアドベントカレンダーをやっていきます！ qiita.com この記事はその第一日目となります。 みなさん、マイクロサービスの開発ってどうされてますか？ HRBrainでは現在マイクロサービス構成をとっており、日々の開発では個人のマシン上で各サービスを立ち上げて動作確認やデバッグができるようになっています(以下、ローカル開発環境と呼びます)。サービスが成長するとともにこの環境にも課題が出てきました。 これを改善するため「Tilt」というソフトウェアを試したところよかったので、今はTiltベースのローカル開発環境に乗り換えています。 Tiltに関する日本語の情報もまだ少なそうなので、今回は一つの導入事例として紹介してみようと思います。 本記事ではまず弊社の抱えていた課題に触れ、次にTiltの概要を説明
メルカリShops の技術スタック、その後 | メルカリエンジニアリング
こんにちは。ソウゾウのSoftware Engineer(CTO)の@suguruです。連載：メルカリShops 開発の裏側 Vol.2の1日目を担当させていただきます。 去年、2021年に開始した メルカリShopsの技術スタック についての記事を書きましたが、今回はリリースまでに採用した技術スタックが、半年通してどのようにアップデートしてきたかを共有したいと思います。 ローンチ時に採用した技術が、実際の運用でどのように変遷したのかを共有することで、技術スタックを考える際の何らかの参考になれば幸いです。 monorepo メルカリShops ではサービスに必要なコードを1つに集約する monorepo を採用しています。リリース後半年たってコード量はかなり増えてきましたが、monorepo に対する満足度は非常に高く、うまく機能しています。 サービス全体の見通しが良くなることと、すべての
メルカリ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 等を使い、そのプロビジョニングや起動・停止等は
メルカリShops の技術スタックと、その選定理由 | メルカリエンジニアリング
こんにちは。ソウゾウの Software Engineer (CTO) の @suguru です。連載：「メルカリShops」プレオープンまでの開発の裏側の1日目を担当させていただきます。 7月末にメルカリShopsという新しいサービスが公開されました。メルカリShops は、2021年1月にメルカリのグループ会社として設立したソウゾウが新たに立ち上げたサービスです。 この記事では、メルカリShops を作るにあたり、どういった技術、アーキテクチャを選定したのか、その背景と意思決定をまとめて共有したいと思います。 monorepo まず最初にプロジェクトをスタートしたときに、サービスのリポジトリを作るのですが、迷わず monorepo による構成を選択しました。monorepo は、システムを構成する複数のコンポーネントの独立性を保ちつつ、全ての構成を1つのリポジトリで管理する手法です。今
大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
こんにちは、SWETでCI/CDチームの前田（ @mad_p ）です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容
GitHub における大規模なモノリポのパフォーマンスの向上
GitHub は、毎日 5600 万人以上の開発者にサービスを提供し、2 億以上のリポジトリをホストしています。これらのリポジトリのごく一部を除いて、世界中の顧客に驚くべきパフォーマンスでサービスを提供しています。 GitHub のような大規模なシステムでは、コードとアーキテクチャのずれというのは限界に達したときに初めて見つかるものです。例えば、何千人もの開発者が毎日同じリポジトリを更新するといったケースです。GitHub は、大規模なモノリポを使用する一部の顧客から、プッシュ操作が失敗するといったパフォーマンスの問題が発生しているというフィードバックを受けました。 そして、それは GitHub においても発生していました。 github/github は GitHub のモノリポですが、私達自身も時々プッシュに失敗することがありました。 調査を開始するにあたり、私たちは社内のチームや顧客
GitHub - aspnet/AspNetCore: ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
ASP.NET Core is an open-source and cross-platform framework for building modern cloud-based internet-connected applications, such as web apps, IoT apps, and mobile backends. ASP.NET Core apps run on .NET, a free, cross-platform, and open-source application runtime. It was architected to provide an optimized development framework for apps that are deployed to the cloud or run on-premises. It consis
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
One Version to Rule Them All: Keeping Your Python Package Version Number in Sync With Git and Poetry | Nadeau Innovations
The One Version Rule | Google Open Source
GitHub - irahardianto/monorepo-microservices: Working implementation of monorepo microservices in Go with MongoDB and Kubernetes