ハクソク

世界を動かす技術を、日本語で。

GitLabが好きです

121日前原文(whileforloop.com)

概要

  • GitLab を長年プライベートプロジェクトで利用している理由の解説
  • Docker Registry やCI/CD機能の活用例
  • GitLabの 利点と不満点 の整理
  • GitHubとの 使い分けの実態
  • 個人ワークフローにおける GitLabの立ち位置 のまとめ

GitLabを選び続けている理由

  • GitHub がプライベートリポジトリを有料にしていた時期、 GitLab は無料で提供
  • 小規模なプロジェクトや実験用リポジトリの非公開管理に最適
  • GitHub も後に無料化したが、既に GitLab 中心のワークフローを構築済み
  • CIパイプライン、Dockerイメージ、デプロイスクリプト等、全て GitLab に統合
  • 既存の仕組みを変える理由がなく、そのまま GitLab 継続利用

Docker Registryの魅力

  • 各プロジェクトに Container Registry が標準搭載
  • ローカルやCIでイメージをビルドし、 レジストリにプッシュ→必要な場所でプル
  • Docker Hub のアカウントやプル制限、トークン管理不要
  • プライベート用途なら GitLab Registry だけで完結
  • 10GB/プロジェクトの制限は実質問題なし
    • 古いタグのクリーンアップやレイヤ共有で容量効率化

GitLab CI/CDの活用

  • gitlab-ci.yml をリポジトリに追加するだけでCI/CDが始動
  • 設定ファイルもバージョン管理され、過去のパイプライン履歴も追跡可能
  • 基本的な流れは「ビルド→プッシュ→(必要に応じて)デプロイ」
  • デプロイ時の手動トリガーで本番反映のタイミングを制御
  • GitLabの共有Runner は無料で十分信頼性あり
    • 特殊なニーズはVPS上にRunnerを自前設置で対応可能
    • Runnerのセットアップも簡単（インストール→トークン登録）
  • CI/CDのドキュメントは詳細だが、機能が多すぎて最初は探しにくい
    • 慣れれば自作設定のコピペで効率化

不満点と課題

  • Webインターフェースの速度 が遅い印象
    • マージリクエスト、パイプライン、ジョブログの表示で待機時間発生
    • 近年は改善傾向だが、 GitHub ほどの快適さは未達
  • 機能過多（Feature overload）
    • 課題管理、プロジェクト管理、Wiki、スニペット、パッケージ・コンテナレジストリ、セキュリティスキャン等
    • 実際に使うのはリポジトリ、マージリクエスト、CI/CD、コンテナレジストリ程度
    • 必要になれば他機能も利用可能という安心感

無料で得られる価値

  • プライベートプロジェクトを約12個運用中
    • アクティブなサイドプロジェクトから放置中の実験まで
  • これらを 無料で運用できるコストパフォーマンス
  • プロトタイプや実験、未公開アイデア等、 誰にも見られないデジタル作業場 として活用

GitHubとの使い分け

  • GitLab ：プライベートな実験・開発・アイデア管理の場
  • GitHub ：公開して他者に見てほしいものの発表・共有
  • 両者を併用することで、 用途ごとの最適な環境 を実現
  • すべてをGitHubやGitLabに寄せる人もいるが、自分は 両立運用 が快適

まとめ

  • GitLab はプライベート用途での 統合開発環境 として非常に便利
  • Docker Registry や CI/CD の無料利用が大きな魅力
  • 機能の多さや速度面に課題はあるが、 コストゼロ で得られる価値は高い
  • GitHub との使い分けで、 公開/非公開の棲み分け が明確
  • 今後も GitLab をプライベート開発の拠点として活用予定

Hackerたちの意見

ちょっと脱線するけど、素晴らしいウェブサイトだね。正直言って、読むだけでもクリックするだけでも楽しかったよ。デザインやアイデアが自分のものなのか、Jekyllのテーマの一部なのかは分からないけど、実行が本当に素晴らしい。GitHubのリポジトリでソースを見つけられなかったけど、もしかしたらちゃんと探してなかっただけかも。

└

ダークテーマが心地よく読める数少ない例の一つだね。

└

同意！これは素晴らしい個人ウェブサイトだね。

└

同意。アイデアの実行がセンスあるね。マークダウンをそのまま表示するのがクールだと思った人、すごい :)

プライベートプロジェクトのためにGitLabからForgejoに切り替えたんだ。GitLabのインターフェースが遅すぎてもう耐えられなかったからね。ちゃんとCIもあるし、課題追跡や他の必要な機能も揃ってるけど、インターフェースは瞬時に読み込まれるし、プライベートプロジェクトには使わない機能で画面が埋まることもないから最高だよ。

└

以前のForgejoに関するHNのディスカッションへのリンクだよ。 https://news.ycombinator.com/item?id=42753523

└

GitTea/Forgejoが軽量なのが好きな理由の一つは、ローカルでargocdを使って開発できるから。TiltでKubeクラスターを立ち上げて、Forgejoをブートストラップして、Argoを指して、今はローカルでAppsetの開発を同期波でテストできる。

└

ここに書きたかったことがあるんだ。何年もGitLabをセルフホスティングしてたけど、Forgejoに切り替えたら全然不満ないよ。記事ではGitLabの主要機能としてコンテナレジストリが挙げられてるけど、Forgejoにもあるからね。さらに、Forgejoは全体的にスピードがめちゃくちゃいい。リソースの要求も（ざっくり計算だけど）GitLabの10%くらい。もうGitLabを使う理由が見当たらない。ちょっとした不満はあるけど、致命的なものではないよ。まず、GitLabのCIの構文の方が好きだな。「GitHub Actions」はごちゃごちゃしてるし。支配的なゴリラ（GitHub Actions）を使うのは分かるけど、このCIに移行するのは思ったより手間がかかった。あと、ForgejoのAPIはまだまだ発展途上だね。GraphQLを使って探るのは楽しかったけど、Forgejoにはそれが全然ない。でも、データベースに直接アクセスできるから（sqliteやpostgresも選べるし）、カスタムスクリプトで好きなことができるよ。ForgejoのAPIとその周りのインフラはちょっともっさりしてるけど、大きな問題ではないかな。

└

ちょっと試してみたけど、めっちゃいい感じで超サクサクだね。CI部分はWoodpeckerってプロジェクトが提供してるみたいだけど、これってどういう仕組みで、GitLab CIと比べてどうなの？

└

Forgejoのコードレビューツールは、GitHubに忠実に従っていて（他の多くの機能もそうだけど）、そのせいで同じように劣った開発フローになってる。GitLabはGerritじゃないけど、少なくともスタックされたMRをサポートしてるし、強制プッシュやリベースの間にコメントを見れるのはいいところだよね。私はCodebergを使ってるから、オープンソースプロジェクトにはForgejoを使ってるけど、正直言ってGHスタイルのワークフローは真剣なソフトウェア開発には向いてないと思う。全てのコミットを潰すか、マージコミットを使うことを強要されるからね。多くの人がこの状況に慣れてしまって、他の方法を想像できないみたいだけど、本当にダメだと思う。GHモデルは一気に大きなPRを作ることを促進していて、生産性やチーム内のレビュー文化に悪影響を与えてる。しかも、git履歴に汚いコミットが残るし（「レビューコメントの修正」「マージ」「レビューコメントの修正」とか）。私は仕事でGitLabを1年半使ったけど、機能的にはGitLabのレビューツールの方が好きだな、UXは別として。

└

Forgejoに切り替える意味ってあるのかな？Microsoftじゃなくて、Codebergとかの人たちからリソースを吸い取るだけになっちゃう気がするんだけど。

統一されたインターフェースがあるのは素晴らしいけど、ちょっとしたストレスが多いね。私にとっては、いつも古い問題の流れにハマるのがちょっとしたミームになってる。「Xをやりたい→試してみる→問題にぶつかる→解決策を探す→3〜8年前の公式バグレポートを見つける」みたいな感じ。多くの機能が80/20の地獄にハマっているか、「機能リストに箇条書きを追加するために、ほとんど動かないMVPを作った」状況に見える。コメントでも言われてるけど、遅いインターフェースはMRビューで本当に痛い。時々、イライラするよ。

└

私にとっては、いつもこの古い問題の流れにハマるのがちょっとしたミームになってる: Xをやりたい -> 試す -> 問題にぶつかる -> 解決策を探す -> 3-8年前の公式バグレポートを見つける。これが私の経験でもあって、実際、前のクライアントでは完全にミームだったよ！

仕事で5年前にGitLabに切り替えたんだけど、これが私の体験を完璧にまとめてる。さらに、GitLabプロジェクトにはMaven、NPM、Pythonに対応したパッケージレジストリも含まれてるから、CIパイプラインにパッケージを簡単に戻せるのが小さなチームとしてはお気に入りの機能。逆に一番嫌いな機能は、機能の数が多すぎること。実際、機能が多すぎるんだよ。そして、常に待たされるのもね。基本的に、どの画面も待つ時間が倍になってる感じ。

└

仕事でStashを長いこと使ってからGitLabに切り替えたんだけど、すごくリフレッシュされた。速いし、セルフホスティングで、機能も豊富で、特に品質ゲートやPRのビルド周りが便利だった。それから、最適なスイートを目指すことになってAzure DevOpsに移行したんだけど、もう遅すぎて。課題もコーディングよりプロジェクト管理寄りになって、品質ゲートはほとんど存在しないし、ビルドも遅くなった。ビルドが遅いのは、強力なビルドサーバーの代わりに、サイズが小さくてIOPS制限のあるVMで動かしてるから。MavenやDocker、NPMのキャッシュをダウンロードするのは比較的早いけど、ディスク上で展開するのは遅い。ジョブを起動するためのオーケストレーションも遅いからね。GitLabに戻りたいし、パフォーマンスを調整するために時間をかけて貢献したいと思ってる。GitLabはすべてをうまくやってると思うよ。（技術的には、価格やティアについてはよく分からないけど。）

スピード。GitLabのウェブインターフェースは、ずっともっさりしてると感じてた。10年経っても同じ問題が残ってる。GiteaやForgejoはパフォーマンスの問題がほとんどないし、Go 1.26が出たらさらに良くなるはず。これは単なるバージョン番号のアップグレードよりもずっと大きなリリースだよ。

└

トラックは小型車よりも常に鈍重だよね。企業向けのものと、小規模プロジェクト向けのものでは全然違う生き物だよ。

└

GitLabみたいにサブプロジェクトフォルダがあればいいのに。すぐにでも乗り換えたい！

└

GitLabはプライベートプロジェクトのリモートリポジトリとしてしか使ってなかったから、CIは全く使ってなかった。遅いインターフェースと、時々出てくるあのブラウザチェックのせいで、アカウントを閉じちゃったよ。

└

GitLabには根本的なアーキテクチャの問題があるんだろうね。仕事で使わなきゃいけなかった時、スピードにやられた。特に問題を検索するのがひどかった。パフォーマンスを向上させる方法が見つかるまでは、GitLabを使うことは考えないよ。

└

Go 1.26が出たらもっと良くなるよ。誰か理由を教えてくれる？Go 1.26で何が変わるの？

└

すごく変だな、私の経験は逆だよ。2018年に転職したとき、BitbucketとConfluence（自社データセンターだけど、私の理解ではパワフルでよくメンテされてた）からGitLabクラウドに移ったんだ。Atlassianは遅くて、オーバーエンジニアリングされてて、使いづらかった。GitLabはスリムで速かったよ。それ以来、いろいろ機能が追加されたけど、レスポンスが少し悪くなったかもしれない。でも、文句は言えないかな。GitLabはほとんどの時間うまく動いてるし。最近はJiraクラウドを使うことがあったけど、GitLabよりずっとひどい。テンプレートが overloaded になってるのか、特に悪い拡張機能があるのかもしれない（XRay、見てるよ）。でも、かなりもっさりしてて、イライラするユーザー体験だった。GitLabでは、過剰に興奮したマネージャーがテンプレートにどんどん詳細を追加してもパフォーマンスを台無しにすることはないからね。

└

CI/CDを有効にするだけで、GitLabがCPUコアのほとんどを永遠に使っちゃうんだ…驚きだよ。

初期の頃からGitLabを使ってたけど、1週間前にForgejoに切り替えたんだ。サーバーの電力使用量が10%減ったよ、どちらもほとんどアイドル状態だったのに。著者が言うように、GitLabはもっさりしてるし、使わない1001の機能で膨れ上がってて、UIが使いづらい。必要ない機能が多いけど、逆に無料版では使いたい機能が無効になってることもある。Forgejoはシンプルで、必要ない機能をプロジェクトごとに隠せるのがいい。ただし、いくつかのトレードオフがある。GitLabのアップデートは素晴らしかった。何年も問題なく自動更新させてたけど、Forgejoではそれがうまくいかない。Forgejoは全体的に洗練されてないし、いくつかの機能は本来のように動かないみたい。

GitLabを嫌ってる人がいるなんて知らなかった。仕事で使ってるけど、改善すべき点はあるにしても、全体的には直感的で使いやすいと思ってる。管理者とグループレベルでのユーザー管理はもっと改善できると思う（管理パネルではLDAP同期設定が見えないから、グループに移動しないといけないし）。でも、使っててイライラすることはないよ。CICDの構文も大体は楽だしね。

└

CICDの構文も大体は楽だしね。全然同意できない。GitLab CIは、いくつかの代替品よりも強力だけど、めちゃくちゃ悪いし、そのYAMLベースの構文も含めてね。別のスレッドでも言ったけど、 > 2021年から2024年まで毎日GitLab CIを使ってて、GitLabで遭遇したバグや驚きの挙動を記録する日記をつけ始めた。CIパイプラインのコードに触れるたびに、また別のGitLabのバグにぶつかるのは確実だった。

└

UIがすごく嫌い。めっちゃ混乱する。GitHubの方がずっと使いやすいのに、なんでGitLabはこんなに複雑にしようとするのか理解できない。

GitLabを使うのは好きだけど、IPOの影響で派手なものを追い求めるようになって、品質への注意が減った気がする。顧客が使ってたサポート担当者がいなくなって、今は全部営業を通さないといけなくなったし、大半の機能が高額なUltimateプライスタイアの後ろに隠されてる。可愛い機能もたくさんあるけど、AIじゃないから無視されてる感じ。何年も同じ問題を抱えてる顧客がいるのに、オープンな問題があるのにね。これがゲームみたいになってる。「AIツールの大勝利を謳うセールスピッチが来るたびに、GitLabの開発がIPO前のスピードに戻るのはいつ？」って聞くようになった。

└

いや、彼らはいつも派手さを追い求めてたよね。2015年から2020年頃は彼らの製品を使うのが楽しかったけど、ほんとにパレートの法則に頼りすぎてた。どの機能も粗があって、仕上げにあまり投資してなかった。小さなチームが巨大企業と競うのは厳しいトレードオフだし、彼らの成功はその戦略が正しかったことを示してるんだろうね。企業向けを狙うなら、各機能を完璧にするよりも、必要な機能を揃える方が重要になることもあるよね。

プロジェクトごとの10GB制限は、見た目は小さいけど、実際には一度も近づいたことがない。Dockerイメージには制限がなく、レイヤーごとに制限がある。確か、無料プランで100GBのイメージを配布したことがあるよ（レイヤーサイズを小さく保つ必要があったけど）。更新：ソース https://docs.gitlab.com/user/storage_usage_quotas/ https://gitlab.com/gitlab-org/container-registry/-/issues/10...

└

誰か、4K映画をいくつかのDockerレイヤーに分割してOCIレジストリを通してプッシュ＆プルするp2dを作った人いる？インターステラーの70GBのREMUXコピーがあるから、これをGitLabにdocker pushしたいんだ。

└

無制限のサイズ、無制限のプッシュ/プルが無料で、レイヤーが10GB未満なら？それが正しい理解？

機能過多。GitLabは全てになろうとしてる。これが私がGitLabを嫌いな主な理由。使うのがすごく複雑なんだ。GitHubのイシュートラッカーはすごくシンプルで使いやすい。プロジェクトオーナーには多機能を提供してるかもしれないけど、ユーザーとしてはやっぱりGitHubの方が好きだな。もちろん、MicrosoftがGitHubを支配してなければもっと好きなんだけど…

└

同じく。機能もちゃんと実装されてないしね。これが理由だと思う。

└

同じく。以前、企業でGitLabのインスタンスをホストしてたんだけど、たまに使うシステム管理者として言わせてもらうと、何かをするのに実際にやるよりも、どうやってやるかを理解するのに100倍の時間がかかったよ。ソースコードやイシュートラッカーを見つけるだけでも、ナビゲーションの層に隠れてる感じだった。今はGitHubをホストしてるけど、ほんとに楽になった。GitHubにも嫌なところはあるけど、GitLabの何よりもマシだよ。GitLabは大嫌い。