Organizationの非公開リポジトリで管理して、今まで通りCIやりましょうというお話。Gitlab時代ForkやPRという概念がなかった。Requestという機能はあったけれど。pluginが受け取りビルドするという流れだった。さあ、GithubOrganizationに非公開の親リポジトリがあり、そこにメンバーがForkしたリポジトリがぶら下がる形。OSSの開発と似たような感じだけど、非公開リポジトリなので当然外からは見えない。(非公開リポジトリをForkしたら、メンバーのGithubアカウントがFreeアカウントでも非公開になるんだね!)上記の構成で下記を実現する。親リポジトリのmasterにpushしたら、本番環境にデプロイされる。親リポジトリの開発ブランチにpushしたら、ステージング環境にデプロイされる。個々のリポジトリの開発ブランチにpushしたら、個々の専用のステージング環境にデプロイされる。開発者毎にステージングがあるのがポイント。開発者毎のステージングで問題がなければ、親リポジトリの開発ブランチへPRを投げる。それを実現する過程で問題になった点/気になった点をいくつか。セキュリティ対策Githubにして問題になったのは、まず外部のネットワークということでセキュリティを気にしないといけなくなった。ここでは割愛するけれど、Jenkinsの管理から権限をしっかり設定すべき。pluginこれドキュメントがなさ過ぎるんだけど、要するに自分のgithubのid/passwordをJenkinsに入力すると自動でやってくれる。これ楽だけど、気持ち悪い。keysに貼っつけてもいいのだけど、そうすると複数リポジトリを持つときに困ったことになる。Organizationの親リポジトリだけでなく、個々のForkしたリポジトリからのデプロイもやるので、複数のリポジトリにJenkinsから繋げないといけない。pem_for_user1こうすると、当然、Jenkinsの設定でもGitのリポジトリ名をgit@production.github.com:hogehoge/hogehogeみたいに書かないといけない。pluginがGithubからのHookを違うものと認識してしまって動かない。実装を考えると当然かと思うのだが。keysにJenkins用の鍵を追加してやらないといけない。keysに追加していただく。ここらへんまでやると動く。個人のアカウントにJenkins用の鍵を追加するのは気持ち悪すぎるので、他の方法があれば採用したい。cloneできちゃうわけだしね!!)ただ、仕組みとしては最高に使いやすいです。upLoginユーザーは見つかりませんでした。