1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2016-12-11

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

前提条件

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

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

結論

  • こんなことになった

image.png

これって変?

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

実際の実装

結論の図では若干省略していますが実際には以下のように流れるものを作りました。

  1. 開発環境でdevelopへのmergeが起きると,開発環境にいるjenkinsが開発環境のサーバにデプロイしてテストを回す
    1. が成功したら(自動で|手動で)masterへmerge
  2. 共通git環境のjenkinsが2. を監視していてmasterに差分があればclone --mirrorを実行
  3. 共通git環境のgitlabにpush --mirrorを実施
  4. 4.が成功したら共通gitから検証サーバにデプロイしてテスト->商用サーバにデプロイしてテスト

良くない点

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

終わりに

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

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?