デブサミ2019のメモです
Github
いきなりプルリク 感動的な経験
- 入社して最初にやるべきこと、読むべき文書など
- 社内ドキュメントのURL間違いを発見
- 自動でレビューワが設定され、CIが走る
- 5分後くらいにレビューOK
InnerSource的な文化
- オープンソースに対してのインナーソース、社内でもオープンソースのように管理しましょう
- オープンソースのベストプラクティスを企業の中でもやりましょう
InnerSourceの目指すところ
- コードの再利用
- コミュニケーションコストの改善
InnerSourceをいかに根付かせるか？
- 組織の文化を変えるのが大変
- ツールを導入することで人の行動が変わる、文化が変わるきっかけ隣る
githubを使ったプラクティス
- 基盤を統一（他の人が見えるように、明確な理由がない限りパブリックに、検索できるように）→あらゆるコンテンツにURLがつくられる
- それぞれにURLが含まれるのは超重要。以前検討した結果などの共有が可能となる。
- コントリビュートの敷居を下げる（他のチームからのコントリビュートを「歓迎」コメント）
- Readmeにコントリビュートが価値があること、どういう手順でできるかを記載する、
- CONTRIBUTING.mdをルートに作ると、外の人がプルリクやIssueしようとすると表示してくれる。
- Seleniumにもあった！（当たり前） https://github.com/SeleniumHQ/selenium/blob/master/CONTRIBUTING.md
- ワークフローの自動化（レビューワを自動で設定、マージ可能となる条件の明確化、ドキュメント自動生成、ほか）
- だれにレビューをお願いするかわからない、あるある。
- レビューワ：
*.js ＠frontend-team, *.go ＠backend-team /buils/logs/ ＠infra-team
- CD + Protected Branch
- 何が通らないとマージにならないのか？明確にする。
- GithubPagedを使って、プルリクをマージしたらデプロイまで自動でドキュメント生成
- GitHubber GitHub社内サイト。マークダウンでリポジトリ管理、間違えてたらプルリク送ったりしてる
- GitHub Actions ワークフローのトリガー作れる。
- Issueが登録されたら「ありがとうございます」botとか
- マージすみのブランチを消す（手作業？自動化するといい）
- マークダウンの目次を自動生成など。
まとめ
- 基盤を統一しましょう
- コントリビュートの仕方を明確にしましょう（コントリビュートの敷居を下げる）
- ワークフローを自動化しましょう（コントリビュートの敷居を下げる）
PayPalの例
- 社内でInnerSourceの取り組みを始める。この言葉もPayPalが作った。
- 横軸で社内コミュニティ（デザイナ、セキュリティ、DBなど、、、）を作ってInnerSourceを促進
遭遇した課題
- 他チームのPR（プルリク）レビューをだれがやる？フロントエンドチーム宛ならフロントエンドのだれ？じ分のプロジェクトを優先しがち。→コントリビュートする文化が根付かない。
- 新しい役割（＝他チームからのイシュー対応、プルリクレビュー、ドキュメント整備）を作成
- →放置されないには有効だった。
- 開発者には嬉しくない仕事（コード書かないし、、、）、常に一人の人がやることも問題（まかなえる範囲じゃない）
- →スプリントごとの当番制にした。当番表もドキュメント化。得意な領域もドキュメント化。例えば、画像を直した、などならコントリビュータがデザイナが担当の週にプルリクを送る。
参考資料
- GettingStarted with InnerSource 無料のebook 導入的内容
- Understanding the InnerSourceChecklist 無料のebook わりと具体的な事例
- InnerSource Commons ・・・Paypal中心とするInnerSourceを推進する団体のサイト
- Open Source Guides ・・・オープンソース活動のベストプラクティス、日本語化プロジェクト推進中、「レビューしてくれる人がいたら歓迎します」
感想
- 一言で言い尽くせない感動があった。こういう文化のところあるんだ。
- リンク切れなんてしょっちゅう起こってるしリンク切れしたメールが転送されてくるよ。
- それを会社に導入したときの話も聞けてよかった。絵に描いたもちじゃない、説得力がある。
- 「レビューします」有言実行する。（英語力に問題はあるかもですが）