Help us understand the problem. What is going on with this article?

gitlab同士をうまく連携させたかった話

More than 3 years have passed since last update.

2つのgitlabをうまく連携させたかった話

前提条件

次のポリシーで各環境のコードマネジメントをしたい、ということがありました

  • 開発環境は複数ありそれぞれにgitlabがある(複数システムを開発する)
  • それをまとめるための共通用のgitlabがある
  • 開発環境 -> 共通環境はNW的に疎通不可(FWで落とす)
  • 共通環境 -> 開発環境は疎通可

結論

  • こんなことになった

image.png

これって変?

私はgitでの大規模開発をしたことがないので、始めに前提条件を聞いたときイケてるのかイケてないのかよくわからなかったのですが、
https://git-scm.com/book/ja/v2/Git-での分散作業-分散作業の流れ#統合マネージャー型のワークフロー
というプラクティスもあり(NW要件を除けば)大規模な複数システムの開発をまとめていくやり方としては悪くないように感じました。(詳しい人助けてください)

実際の実装

結論の図では若干省略していますが実際には以下のように流れるものを作りました。
1. 開発環境でdevelopへのmergeが起きると,開発環境にいるjenkinsが開発環境のサーバにデプロイしてテストを回す
2. 1. が成功したら(自動で|手動で)masterへmerge
3. 共通git環境のjenkinsが2. を監視していてmasterに差分があればclone --mirrorを実行
4. 共通git環境のgitlabにpush --mirrorを実施
5. 4.が成功したら共通gitから検証サーバにデプロイしてテスト->商用サーバにデプロイしてテスト

良くない点

  • 開発でmasterにマージがあるたびにcloneしてきてしまうので開発環境がすごい増えたら耐えきれなくなるかもしれませんし、帯域を圧迫しかねません
  • clone --mirror & push --mirrorを使っているのですが、完全に理解して使っていないので良くない手法である可能性があります。
  • jenkinsからshellでclone --mirror & push --mirrorをしているため属人化する可能性が否めません(jenkinsおじさんの誕生)
  • デプロイ&テストはansibleやserverspecを使ってコードマネジメントできるようにしていますがshellを使っちゃってるのでjenkinsのコードマネジメントができていません

終わりに

今回はあまり触れませんでしたが、git-flowなどのブランチモデルも考えつつ今回の構築を行いました。
gitを使った複数人開発でのベストプラクティスを学びつつできたので自身のために良かったです。

renjikari
SREやってます
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away