本文へ
ハクソク

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

HNに聞く: GitHubの代替案

元記事:

概要

  • Github のダウンが数か月間頻発
  • サービスの信頼性低下が懸念材料
  • 代替サービスへの移行を検討する価値
  • 移行時のメリット・デメリットの整理
  • チームやプロジェクトに最適な選択肢の評価が必要

Githubのダウン頻発とその影響

  • Github のサービス停止が 開発フロー に与える影響
  • コード管理や CI/CDパイプライン の停止による生産性低下
  • オープンソースプロジェクトやチーム開発での 信頼性への不安
  • 障害情報や復旧対応の 透明性 の重要性
  • 長期的な 運用リスク の再評価

代替サービスの選択肢

  • GitLab
    • オープンソース版の提供
    • セルフホスティング 可能
    • CI/CD機能が強力
  • Bitbucket
    • Atlassian 製品との連携
    • プライベートリポジトリが無料
  • Gitea
    • 軽量で 自己運用 向き
    • シンプルなインターフェース
  • SourceForge
    • 歴史あるオープンソース向けプラットフォーム
    • プロジェクト管理機能を搭載

代替サービスへの移行メリット・デメリット

  • メリット
    • サービス停止リスク の分散
    • 独自運用による 柔軟なカスタマイズ
    • コスト最適化や データコントロール の向上
  • デメリット
    • 移行作業 の負担
    • ユーザーや開発者の 学習コスト
    • コミュニティやエコシステムの規模縮小

移行判断のポイント

  • プロジェクトの 規模 や 重要度 の見極め
  • チームの 技術力 やリソース状況
  • サービス停止 が業務に与える影響度
  • 長期的な 運用コスト やサポート体制の比較
  • セキュリティ や 法的要件 の確認

結論：移行の是非

  • 頻繁なダウンが 業務継続 に重大な影響を与える場合、 代替サービスの検討 は合理的
  • 小規模・個人利用では 様子見 も選択肢
  • チームやプロジェクトごとに 最適解 を選ぶ柔軟性が重要

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

https://tangled.sh

└

プライベートリポジトリの設定と運用はどれくらい簡単なの？すごくクールな機能がたくさんあるみたいだし、スタックされたPRや、呪術サポート、Nix VMでのCIもあるみたい。でも、デフォルトだと分散型のピアツーピアな公共のものっぽいから、試したことがないんだよね。

└

これが初めて聞いたけど、彼らは若くて賢くてエネルギッシュなチームで、素晴らしい軌道に乗ってるみたいだね。atprotoの選択は面白いし、彼らの社会的な目標にぴったりだね。

https://forgejo.org/

└

彼らのCIとCDのワークフローは、GitLabやGitHubみたいにしっかりしてるの？

└

「Forget Joe」、ギットリポジトリホストにはあんまり良い名前じゃないね。

別のスレッドでこの件について答えたんだけど、もし大きなGitHubの組織を運営してるなら、機能面ではGitLabが一番近い代替品だよ。大きな利点は、自己ホスティングできるオープンソースのコミュニティエディションがあることだね。

自己ホスティングのGitLabを提案してる人たちへ：うちの会社では6年以上やってたけど、いつもスムーズにいくわけじゃなかったよ。自分たちのランナーを使ってて、ビジネス開始前に毎日Dockerイメージを自動アップグレードしてた。ほとんどはうまくいってたけど、Dockerのアップグレードをロールバックしなきゃいけなかったり、デフォルトでpg_shared_buffersが1MBに設定されてて、大きなインスタンスのスキーマアップグレードができなかったり、メジャーバージョンのアップグレードでパイプラインの期待が壊れたりして、200以上のリポジトリを一度にアップグレードしなきゃいけなかったこともあった（その後はメジャーに固定したけど）。最近は、クリティカルな脆弱性のためにほぼ毎週「クリティカルパッチ」のニュースレターが届いてたけど、これはコードをLLMが走らせてバグを見つけてるからだと思う。そういうわけで、GHに移行しなければよかったな。自己ホスティングのインスタンスは、たぶんちょっと遅かったけど、ダウンタイムがずっと少なかったし（経営陣がコストを節約してた）、ちょっと手間がかかったけどね。GHはエンタープライズ向けには全然足りてないし、全体的にダウングレードした感じがする。GLはアクセスの粒度が良くて、ドキュメントも優れてるし、統合もいいし、UIもかなり手が入ってるのがわかる（ただ、新しいアカウントでサイドバーのサブメニューの迷路の中で適切なアイテムをピン留めするのに10分かかるけど）。コードを見たり、必要なら手伝ったり、単にDockerマウントを通じてパッチを当てたバージョンを提供することもできるよ。もし小さめのチーム（50〜100人）で自己ホスティングのGitLabを考えてるなら、少なくとも16GBのマシン（32GBがベスト）に4コアと decent SSDを用意して、ちゃんとメンテナンスできる小さなチーム（1〜3人）を用意しておくといいよ。ランナーには、小さなk3sクラスターが理想で、リソースを気にせずに使えるからね。

└

まだGitHubに各リポジトリにブランチビューアがないなんて、マジで驚きだわ。

└

カスタムGitLabランナーの設定は最初は面倒だよね！GitLab.comの管理リポジトリを使ったいろんな顧客プロジェクトで何度もそれに直面したから。だから最近、同僚と一緒に「GitLab Runners as a Service」を作ったんだ。自分の管理するGitLabやGitLab.comアカウントでログインするだけで、パイプラインランナーの追加はワンクリックでできるよ！裏では、君のランナー用にHetznerのマシンを用意して、GitLabのグループやプロジェクトに自動で接続するんだ。フィードバックもらえると嬉しいな！ [0] https://rocketrunner.io/

└

GitLabランナーはGitLabの中で一番の失敗ポイントだと思うし、マイクロマネジメントが必要だよね。もし最初から設定するなら、ソース管理にはGitLabを考えるけど、CIには別のホスティングサービスを使うかな。

└

なるほど、DSCIをモノリスアプリケーションとして、gitとCIが同じサーバーにあるなら、32GBのRAMのVMで十分だね。ランナーをホストする必要もないし、k8sクラスターも不要、専任のメンテチームもいらないから、DevOpsのコストもかからないし… 一般的なプログラミング言語を使ったCIパイプラインなら、完全にコントロールできてシンプルだよね。

Hacker Newsで議論の続きを見る