GitHub Japan Constellation Tokyo 2018 〜Day 2 Developers in Business〜
2018/06/13 (水)
9:00 - 17:00 JST
公式サイト：https://githubsatellite.com/
参加申し込み：https://peatix.com/event/366939
ライブストリーミング：https://githubsatellite.com/live-stream/
Twitter HashTag： #GitHubSatelliteTokyo
体調崩したり、ドタバタしていてUPが遅くなってしまい、鮮度も何もあったもんじゃないですが、記録残しておきますー
基調講演：GitHub Enterpriseプロダクトビジョン
公家 尊裕 (GitHub) ジェイソン・ワーナー (GitHub)
（冒頭はDay1と同じ話）
Tokyo向けに作ったロゴ。富士山、東京タワー、桜。桜はブランチを表現。
GitHub上の成長率
- 中国・インドと並んで、日本はTop Growing Countryのひとつ
日本国内IoT市場
- 2017年：6.2兆円
- 電力はスマートメーターへの切り替えが行われている
- 電力自由化後に電気会社を切り替えると、そのタイミングで機器交換される
- エネルギーの利用状況から、生活上の利用傾向分析・推測ができる
- 集めたデータをどう解析して、どんなサービスに還元していくか、がビジネスの勝利につながる
- 2022年：12.5兆円（IDCの予測）
- 2017-2022：14.9% CAGR
日本国内コグニティブ／AIシステム市場
- 2017年：274億円
- 2022年：2947億円（IDC予想）
- 2017-2022：60.7% CAGR
- ソフトウェアの勝負
- 欧米では開発者の奪い合い
- 自動的にエンジニアの給料も上がる（お約束はしませんが）笑
- 欧米では開発者の奪い合い
2030年 IT人材不足
- 79万人（経済産業省）
- 毎年、４〜５万人が不足する計算
- これから若者を育て続けても、間に合う気がしない
- 頑張る？（残業する？）→ 事実上無理
- ツールを使って効率的に開発を進める
- 世界中の色んなエンジニアを集めて、グローバルなチームを作る
- 上記、2. 3. のMix
- GitHubは、4.のアプローチを取っている
GitHub Enterprise
- 日本の企業ユーザの95%が、Enterpriseを利用
- （ここで弊社ロゴ・キター！！）
ジェイソン・ワーナー
Every company is an innovation company
- not software company
- 単なるソフトウェア会社ではイノベーションは起こせない
- 優秀なソフトウェア会社とは？
- 難しい課題のバランスが取れる会社
- セキュリティ
- スケール
- アダプション
- インテグレーション
GitHubの責任
- データ侵害を防ぐ
- コンプライアンスに準拠しつつイノベーションを促進させる
- オープンソースコミュニティへのサポート
- Tokenの漏えい等は自動的に防げたらどうだろうか？
- こういった機能でGitHubは協力できる
- Tokenの漏えい等は自動的に防げたらどうだろうか？
コード革命 → クラウド2.0革命
- Pull Request
- ネットワークエフェクト
- GitHubは統合の支援、ワークフローの管理も支援できる
GitHubがお手伝いできること
- テクノロジーを組織の中でデプロイしやすくする
- 最高の人材を集める
ウェイン・ジン
これから我々がやってくことの紹介
- 4つの投資エリア
- プラットフォーム
- データ
- いかにセキュリティを確保するか
- エコシステム
- いかに拡張していくか
- 開発者
- デベロッパーをなるべく生産性の高い状態にする
プラットフォーム
データ
エコシステム
- GitHubはバージョンコントロールシステムだと思われていた
- コミュニケーション／コラボレーションのツールへと拡大していった
- 今は、マーケットプレイスがあり、サードパーティーの必要なフィーチャーを得ることができる
- アイデア
- コード
- ビルド
- デプロイ
開発者
- GitHubは開発者のためのサービスである
- 開発者の生産性を最大限にする
所感
出だし基調講演はDay1と同じ内容なのかとゲンナリしかけたが、エンタープライズ向けのビジョンや機能の表明により、日本国内は特にGHE比率が高いこともあり、より一層力を入れていくことが感じられた。
ゲスト基調講演：DMM.comのGitHub EnterpriseとCircleCI の活用方法
唐沢 陽介 (株式会社DMM.comラボ)
少ない人員でどうやって生産性を確保しているか？を紹介する。
GHEの構築から運用まで関わっている
- CircleCIの導入・サポートも
- CircleCI1.0を2.0への移行支援
今日話すこと
- （表題）のこと
- GHE導入して1年経って思うこと
GHEの活用状況
- 40くらいの提供サービスのうち、比較的新し目のサービスでGHEの採用が進んでいる
- ほかは、AtlassianのBitbucket（クラウド版）を使っている
- なぜミックス？
- 環境改善チームでBitbucketを試験運用していたら、どんどん現場が相乗りしてきた
- みんな本当はGitHubを使いたかった
- 本気でGHEを導入する検討を始めた
- 4つのサービスが稼働中
- GHE
- CircleCI
- ZenHub Enterprise
- SideCIオンプレミス
社内でおすすめしている利用パターン
- Gitのブランチモデル
- 基本は自由だが、相談が来たらシンプルな２つを紹介する
- Git Flow（簡易版）
- feature / develop / master だけ
- GitHub Flow
- master ブランチへのマージは検証環境へデプロイ
- Tagを打つと、本番環境へデプロイ
- CircleCIのうまい使い方
- ビルド＋インスペクション＋デプロイを実施している
- 素早いフィードバックを得るために
- Docker Executorをつかう
- Cacheを使う
- ダウンロードしたファイルはキャッシュする
- ビルドに必要なライブラリをダウンロードするが、毎回ダウンロードではなく、次回以降は使い回す
save_cache:とrestore_cache:
- Worlflowを使う
- 自動テストと静的解析を並列化する
- テストは全部やるが、静的解析は一部（別条件）など
- 自動テストと静的解析を並列化する
- Machine Executorは非推奨としている
- オンプレ版だと非推奨としている
- ビルドのたびに裏でEC2インスタンスが立ち上がる
- 2分以上必ず待たされる、遅い
- 起動数の変更にサービスの再起動が必要で運用が難しい
- CircleCIですばやくフィードバックループを回す
- 速度を意識していないとすぐに遅くなる
- 少しの工夫で高速化できる
- 困ったらGHEで検索する
jobs ruby filename:config.ymlで言語ごとのビルドジョブ定義を社内で探してベストプラクティスを横展開できる
- ドキュメントはGitHub Pagesで
- GHE → CircleCIビルド → GitHub Pages
- ZenHub Enterpriseで進捗の可視化
- GitHubの中だけで開発業務が回るようになった
導入して1年
- 新規サービスではGHEとCircleCIの採用が進む
- 利用者はサーバやユーザ管理が不要で、すぐにCIを始められる
- .circleci/config.yml でアプリケーションの動作要件が分かる
- 既存プロジェクトも移行できるところから移行
- 悩んでいること
- 対策として個人的にやっていること
- 良いリポジトリを見つけたらスターを付ける
- 少しずつ、この文化が広がってくれれば良い
所感
DockerコンテナベースのCIツールとの連携など、弊社と似たステージにいる認識。すべての既存プロダクトを移行できていなかったり、諸々の課題についても似てより、参考にできるところは取り入れていきたい、リザーブドインスタンスとか。。。
ゲスト基調講演/パネルディスカッション：ソフトウェア開発の変遷と、これから
モデレーター 及川 卓也 (フリーランス技術アドバイザー) 大倉 香織 (株式会社サイバーエージェント) 小林 篤 (株式会社ディー・エヌ・エー) 松野 徳大 (LINE株式会社)
GitHubの10年を踏まえ、今後の10年をうらなう
軸となるテーマ
- 一番進化を感じる技術は？
- 事前に登場や進化を予測していなかった技術は？
- 逆に期待はずれだった技術は？
及川：Git前とGit後で社内の開発は変わったか？ 小林：開発者間のコミュニケーションが多くなった 松野：手元で1回コミットしておけるので、途中の作業を保存しやすくなった。途中からカフェに移動して作業したり、とか。メンバーも分散して作業できるのが嬉しい。 及川：コミュニケーションでいうと、SlackとGitHubをペアで使っているところが多い？ 大倉：GitHubを先に入れたが、Slackに更新を通知させたりして現在は活用している 小林：Chatbotとして「安藤さん」を作って利用している（記事あり）
及川：言語のトレンドとして何が増えて何が減った？ 松野：perlとJavaで開発していた会社が一緒になったのだが、最近はJavaが主流。PythonとJavascriptも増えてきた。Swift/Kotlinもスマホ向けに利用している。 小林：Rubyやgo-lang。最近だとJavaが増えてきている。 及川：最近、Javaが増えた、というのは面白いがなぜ？ 小林：人が増えてくるにつれて、新しい人も理解しやすい意味で、型があったり、キッチリした言語にしようか、という話が出てきた。 大倉：ここ最近はgoが多いが、従来はJavaが多かった。
及川：言語採用はどうしている？ 松野：若い人はperlをあまり知らないので、採用が難しくなる。最近は採用しやすい言語を使うよう考えている 小林：最近はgo-langが流行ってきているので、採用にも効いていると感じられる 大倉：同じく最近はgo中心にプロダクトを構築していて、世の中的にも増えてきている感がある
及川：10年前と今では何が違う？ 小林：インフラでクラウドの進化が大きい、今ではクラウドを選定しないことがほとんど無いくらいになっている 及川：インフラエンジニアの仕事が変わってきている。
及川：10年前に機械学習を意識していたか？それを機械学習またはAIと呼んでいたか？ 松野：10年前は今ほどパフォーマンス広告よりも純広告が多かった。今はどういうユーザが広告をクリックするか？などの分析はやっている。 小林：10年前はAIとか言われていなかった。ルールベースでアルゴリズムを処理する、ベイジアンフィルタをかます、などは昔からあった。それが進化したのが今だと思っている。 及川：Googleの検索だって今となればAIと言われるようなものだが、当時はそういう「ラベル付け」がされなかった。
及川：NVIDIAがこんなに大きくなるとは思っていなかった。 小林：GPUの用途が格段に広がった。
及川：皆様の企業はどういう風に変化しているか？ 大倉：グループごとのCTOが事業に最適な技術を選定するようになってきている。 小林：事業部ごとにCTOを置くようになってきている 松野：だれが開発をリードして、誰が決定してくのか？を明文化するようになってきている 及川：テックリードやCTOという肩書きや役割が明示されるよう、組織の文化が変わってきている。
及川：今、注目する技術？ 小林：自動車産業にむけてのオートモーティブ事業に、ITS（インテリジェントトランスポートシステム）への適用が重要。Uberとかを導入するにあたり、日本は世界に比べて遅れをとっている。土木や都市設計にも関わってくる。次世代の環境を作るためには、日本のITSを底上げしていく必要がある。 及川：日本は要素技術は強いが、応用をする際に、横の連携がまだ足りない感がありますね。 大倉：RPAの導入をしていきたいが、APIが公開されていない（？）など厳しい状況にあるが、できるようになっていきたいと思う。（？） 及川：人間の動きをシミュレートしたり、そういったもので代替されるが、なんとかテックといったものが縦の機能で閉じていて、横の連携をするためにAPIを公開して連携可能にすることで、ユーザーフレンドリーなものが作れるようになっていくのかな、と。 松野：非常に沢山のデータが集まってくる。どういったものを集めて利用していくのか、が重要。気軽に大きなHadoopクラスタを構築できるようになってきたので、その後の扱い方が重要。 及川：データを集めることはできたとして、そのデータをどう扱うのか？が重要だが、データに対するリテラシーはどうやって育てられているか？ 松野：データサイエンティストを積極採用したりしつつ、Tableauサーバなど気軽にBIで分析できる基盤を整えたりしている
①例えば、プログラマとして、どこまでプログラムを書かないといけないのか？ 及川：インフラはほとんどスクリプト一発で実現できることが増えてきている。GitHubのChrisも、将来はコーディングがなくなっていく世界が来ると言っていた。 松野：どういう要件が必要で、どこがどういうコンポーネントで、といった要件を整理するところは少なくとも人がやるんだと思っている。徐々に、ブロックを繋げるだけで実現できる世界が広がってきているのを感じる。 及川：書き方は簡単になってきているが、やろうとしていることが難しくなってきているので、結果的に書く量は変わっていないようにも思える。 小林：自動車産業がなぜこんなに自動化するか？というと、人間が操縦したりすると事故が起きるから。つまり、人間がコードを書くとバグが生まれる、ということの解決としてプログラミングも自動化されていくのではないかと思っている。
小林：RoRなど簡単なものが増えてきた弊害として、裏側の本質的に行われていることを理解していない人が増えてきているのは、どこかで問題につながりうるのではないか。
及川：マインクラフトの話があったが、ビジュアルプログラミングはどれくらい出てきているか？ 大倉：子供向けにスクラッチをやらせてみているが、まだ難しいようだ。子供向けのRubyの本のほうが分かりやすいかと考えている。 及川：ビジュアルプログラミングは、バージョン管理と人とのコラボ（ソーシャルコーディング）が難しく感じる。
及川：将来に向けてインフラエンジニアはどうあるべきか？ 大倉：抽象化されたことで自動化やプログラムで解決されるものが増えてきたが、コードを書くのか、より深い要素技術を理解して身につけるのか、どっちかかと思う。
及川：チェスの大会や、自動運転車の世界でもあるように、機械の横に人間が座って、協力して結論を出していく組み合わせがベストな解決につながる、という世界がしばらくは続くと思う。
②ソフトウェアにより制御可能な世界 SDxやxxx as a service その進化はソフトウェア開発やインフラへどう影響を与えるか （途中、メモれず・・・） 及川：Software eating the world. とも言われるように、ソフトウェアが世界を変える、という流れがしばらく続くかと。
③チーム開発の将来は？VRやARが与える影響は？リモートワークの今後 小林：隣りに座っている人ともSlackで会話する、ということも出てきている。だが直接会って話さないと伝わらない空気感や感覚があるし、初めて会う人がずっとChatというのも抵抗が残るので、対面コミュニケーションはなくならないと思う。 松野：グローバルな拠点でのやり取りはChat(LINE)だったりビデオ会議でやることがある。ビデオ会議でも通訳を通しても通信が不安定だったり、情報が落ちることがある、対面で通訳を通したときの方がまだ安心感がある。今後はVRで徐々に解決されていくのかもしれない。 及川：音声が不安定だと、途切れるのを恐れて、短いフレーズで話す傾向がでてしまい、短い文言での発言だと「怒ってるのかな？」みたいに本来のニュアンスで伝わらないことがある。
最後にひとこと 松野：今後も色んな技術によって、いろいろと便利になっていく、それらに触れられるのが、作る側としても楽しみ。 小林：作り方も高度化している。企画して設計して作って、ではなくユーザ体験とか考慮するようになっている。それらを柔軟に対応できるようになっていきたい。 大倉：今日のディスカッションを踏まえてオートメーション化について今後もディスカッションができると嬉しい。
所感
golang普通に使っている企業が増えてきたなー。生の及川さん初めて見たー（ミーハー心）
GitHubと共に学生を育てる方法
古橋 大地 (青山学院大学)
@mapconcierge
2017年度の大学1年生
文系の学生ですら、ここまではやってるんだな、という話
いつも学生に見せる樹状図
- 生物の進化
- 様々な形で生き残るもの、生き残らないもの
- どういう情報が継承に値するのか？
- どうやって教育していくべきか
教育の中でGitHubを利用している
- GitHubの地図を作っている？
- GeoJSON
- 点情報、緯度＋軽度
- 拡張子は
.geojson
- ベクタデータ全般が扱える
- Github上でレンダリングされる
- 背景地図はGoogleマップではない
- 私達が作っている「OpenStreetMap」
- https://openstreetmap.jp/
- GeoJSON
どんなことを教えているか？
- 課題：XYZタイル画像のデータ仕様を図化しなさい。
- 技術者としてではなく、技術者と一緒に活動できるようになりなさい
キャンパス内でドローンを操作してみる体験
- ドローンレース
- どういう映像がドローンを通して見えるか
- ドローン操作がうまくなる
最先端の技術をどうやって社会実装できるか、を考えられる学生を育成
- OpenStreetMap
- 一億総伊能化
- GitHubに様々な地図情報を提供
Wikipediaを参考にしたモデル
- Free Wiki ...（？）
オープン（＝商用利用可能）
オープンストリートマップ
- 5.0M規模のボランティアの力
- 海外の仲間との情報共有
- 公開にすることで、学生に適度なプレッシャーになる
- 外部の人からコメントが来たりする
- ウェブサイトはGitHub Pages
Gitの仕組みは、Git-it で経験。
- https://github.com/jlord/git-it-electron
- 文系の学生もコマンドを使わせる
- GitHubが使えないことで、そのコミュニティに入れないのは大きな損失である
- 学生に説明するプレゼン資料はSpeakerDeckで公開
- GitHubと空間情報
- GitHubの履歴は就職活動の履歴書にもなる
- 就職活動前から（1年生から）育てていく必要がある
- Issueでのやりとりも、PRもすべてがエビデンスになる
最近は、GitHub Projectでタスク管理
外（社会）と中（大学）をつなぐ架け橋がGitHub
- Publish or Die! （公開するか、さもなければ死を！）
所感
文理系に関係なく、学生にITリテラシーを植え付けようとするその志と、オープンな地図ソリューションで社会貢献しようという情熱が半端なかった。これくらい徹底してGitHub中心に生活させるようにしないと、リテラシーの底上げは実現できないよな、と痛感。
SlerがGitHub Enterpriseを使ったら
原口 猛 (株式会社セゾン情報システムズ)
所属グループ「モダン開発推進」とは？
- 既存のプロジェクトの進め方にプラスアルファをし、いいねを一緒に増やしていく
GHE導入編（SIerでもGHEが使いたい）
- 背景
- いざ導入
GHE運用編（え？運用は私一人ですか？）
- 2年間運用してトラブル０件
- 運用で必要となるのは、定期的なアップグレードのみ
- 運用工数はごくわずか
導入効果
- デイリーコミット（を推奨）
まとめ
- GHEはただのツールではなくプラットフォーム
- 文化を変えるためのプラットフォーム、豊富なプラクティス
- 導入ではなく定着がゴール
運用事例
- 事例１．ペアプロ・モブプロによるシングルブランチ運用
- PRベースじゃなくてFaceToFaceでレビュー
- ブランチはmasterブランチのみ
- 事例２．開発以外での利用例（ポータルサイト）
- GitHub Pages
- 静的コンテンツを簡単に公開
- GitHub Pages
マクニカネットワークス 根本さん
GitHub Enterprise の国内一次代理店
- 導入事例および支援サービスのご紹介
- GHE および CircleCI オンプレ版 の導入支援
所感
GitHub Pages 使っているところが多いなー
弊社でも有効活用しないとなー・・・
GitHub Marketplaceと、開発生産性を向上させる幾つかのSaaSのご紹介
角 幸一郎 (SideCI株式会社)
@sumyapp
コードレビュー支援サービスSideCIのFounder,CEO
背景
- 書籍「クラウド誕生」の出版2009年から9年が経過
- オンプレミスなソフトウェアやソフトウェアのない世界が残っている
- ソフトウェアはお金で買える、開発リソースはお金で買えない
- 開発者は仕事を効率化するために、SaaSやソフトウェアを遠慮なく使える世の中になって欲しい
発表後にやって欲しいこと
- GitHub Marketplaceですぐに使える便利なサービスを知って、使ってみて欲しい
SideCIで使っているサービスは、数多くある
- 10数名規模の会社だが、無数のサービス利用によって生産性を最大化している
GitHub Marketplaceとは？
Marketplaceサービスの紹介
- Coveralls | Code quality
- https://coveralls.io/
- テストカバレッジがいろいろな方法で非常に見やすい
- 行ごと
- ファイルごと
- 時系列
- SideCI | Code review
- https://sider.review/ja
- RuboCopやCheckstyleなどの解析機を使って、コードレビューを支援
- GitHub PullRequestと連動
- コードを解析、問題点をサジェスト
- 静的解析ツールは必ずしも正しい指摘をするわけではない
- 誤検知をCloseする機能あり
- プロジェクト固有のルールも検査できる
- 購入パイプラインによって並列実行も可能
- 今日から sider にサービス名変更
- Dependabot | Dependency management
- https://dependabot.com/
- Dependencyの自動アップデート
- PRを自動で生成
- アップデートでCIが落ちるか？が分かる
- PRを自動で生成
- Rollbar | Monitoring
- https://rollbar.com/
- 例外検知サービス（めちゃ便利）
- スタックトレースが見られる
- ユーザの環境情報も（ブラウザなど）
- 例外のトレンド把握や検索が可能。
- ZenHub | Project management
- https://www.zenhub.com/
- GitHub Issues をボードで表示
- GitHub Projects よりも高機能
- ベロシティ計測、リリース可能日予測
便利なサービスがたくさんある
- 開発生産性を飛躍的に引き上げてくれる
- 簡単に導入できる
- 人の時間は有限。スケールアウトもできない
- SaaSなら人の時間を節約できる
所感
今までは、ほとんど自前でゴリゴリと周辺サービス連携をしてきてしまっているので、マーケットプレイスを有効活用して、楽に（お金で解決して）生産性と品質を確保する選択肢を増やしていかないとな。
GitHubを軸とした開発プロセスのリプレイス
大平 哲也 (株式会社スタートトゥデイテクノロジーズ)
テーマ
- いかに開発者の負担を減らして、楽しく開発できるようにするか
- 主に「自動化」について話します
開発環境を取り巻く状況
- 開発体制
- 基本・内製
- 100名強のエンジニアでサービスの開発と運用。
- 本社と密に連携
- 慢性的な人手不足
- ZOZOTOWNシステムリプレイスプロジェクト
- おおまかな方向性
GitHub導入以前
- 他社のインストール型Git Repositoryを利用
- 様々な問い合わせが発生し、十分に対応しきれない
- サーバが落ちる、ログイン不可、重い
- 社内での運用は人手不足
- インストール版のGit repoだと、各種SaaS/PaaSと連携するために自作○○が必要になる
GitHub機能比較 by スタートトゥデイ（GBHの価格は $21 で、GHEと同じ）
GitHub Business Hosted
GitHubエコシステム
- Wercker（CIツール）
- 自動化
- テスト
- いわゆるUnitTestを実施
- DSLの内容もチェック
- Terraform/Ansible
- コード品質の評価
- push時に品質を自動でチェック
- Code Coverage
- Code Smell
- Duplications
- PRレビューの補助
- SonarCloud（SonarQubeのクラウド版）
- 様々なコードメトリクスを収集
- コード自動生成
- 仕様は一箇所で表現したい
- 仕様を書いたら、そのとおりに成果物ができて欲しい
- Swagger / OpenAPI
- YAML/JSON で仕様を定義
- 定義どおりにコードを自動生成
- Swagger to Mock API
- Swagger to API Code Template
- SpringBootの例（Controller Interface）
- Swagger to API Client Implementation
- Swagger to Spec Document
- API仕様をドキュメント化＋動作確認できる
- Swagger to Postman
- APIテストツールPostman用の設定ファイルを自動生成
- https://qiita.com/moaikids/items/1e05ef2595504689fe3e
- Swagger to JMeter
- 性能テストの元となる設定ファイルも自動生成
- https://qiita.com/moaikids/items/2f0029ea246c5f6818d9
- 成果物のパッケージ
- デプロイ
- ...追いつけず
- テスト
総括
- GitHub Business Hostedを採用することで運用負荷を減らす
- 様々なエコシステムを利用できたので、開発者の生産性を向上
- GitHubをフル活用して開発者が楽しく開発できる環境にしていきたい
所感
k8sを使っている事例を当たり前に紹介されることが増えている気がして、やばい出遅れている感（！）
企業開発に役立つGitHubの最新機能
池田 尚史 (GitHub)
@ikeike443
プリセールスのエンジニア
- ROI計算の支援とかしてる
GitHubとは
- The software development platform
- ソフトウェア時代の主役は開発者であり、それを支援する
- 色んなバリエーションのプロダクトごとに様々な開発手法がある
- あらゆる開発手法を受け止められる開発プラットフォームである
- 10年間に書かれたコード量：500TB
- 昨年1年間のコミット数：15億
- マージされたプルリクエストの数：1億
- 85%のプルリクエストは、実はPrivate（主に企業による利用）
企業利用の選択肢
- GitHub.com Business Hosted
- GitHub Enterprise
- コードベースは同じ
- エンドユーザー視点で同じ機能を提供
- GitHubBH
- GitHub社が運用、マルチテナント、米国
- GHE
- 社内にインストール、御社のポリシーで
代表的な機能
- GitHub Flow（機能というかプロセス）
- GitHubが提唱しているベーシックな開発フロー
- Git Code Repository
- Pull Request
- Issues
- Projects
- 巨大なエコシステム
- 各種ツール、エディタ、チャットツール、CIツールとの連携
企業利用に役立つ機能
- Platform
- Administration
- Org/Team
- Nested Teams
- 権限グループのネスト
- Approval flows
- Teamへのメンバー追加
- Organizationへのサービス追加
- Team Discussions
- チーム単位でディスカッションができる機能
- Organization Permissions
- メンバーの初期権限
- リポジトリの可視性
- Forkの可否
- 2要素認証の使用有無
- Protected Branches
- 特定のブランチを保護し、マージ条件を設定できる
- Code Ownerによる承認を必須に
- CIやテストのパスを必須に
- 特定のチームのみマージ可能
- Nested Teams
- Developer
- Projectsの改善
- 自動化カンバンボード
- Issueのステータスとカンバンの位置移動を連動
- 進捗のビジュアライズ化
- 権限管理
- テンプレート
- キーボードショートカット
- 自動化カンバンボード
- 複数のIssueテンプレート
- ナビゲーションの追加
- 特定言語について、Jumpと編集が楽に
- コメント編集履歴
- Projectsの改善
まとめ
- 企業内開発に役立つ機能
- Issues/Projects/Pull Requests
- Organization/Teamによる権限管理
- 運用管理に役立つ様々な機能
- 今後も進化していきます
- GitHub Changelog で変更点は確認できる
所感
Security Alert / Checks API は待望。
GitHub Enterpriseアドミンパネルディスカッション
モデレーター テレル・ブルーマ (GitHub) 伊集院 圭介 (ブラザー工業株式会社) 井内 聡 (フリュー株式会社) サマーズ ハリス 和弘 (楽天株式会社)
テレル・ブルーマさん @domofactor
１．GitHub導入時点の話 て：導入した理由は？ さ：インフラを導入していく仕組みのリポジトリを管理していくにあたり、GitHubを使えなかったのでGHEを使った て：大規模な企業だが、簡単に導入できたのか？ さ：導入には苦労はなかった 伊：システム的な問題としてプロプライエタリなVCSはWindowsでしか使えず、Mac/Linuxでは別のものを使っていた。ソーシャルコーディングが開発者から求められていた中で、GitHubEnterpriseを使っている他社の事例を見て憧れを抱いていた。そういうCoolなツールを使いたい、という思いが強かった。 井：レビューを強化しようという流れの中で、SVN＋Redmineで行っていたが、GitHubのPullRequestの方が効率的だったので、導入した。.comの利用にはハードルがあったので、GHEを採用した。
て：導入で苦労したことは？ 井：SVNからGitへの履歴を含めた移行はすぐにできたが、SVNの外部参照を多用しており、代替の機能がgitにはなかったので苦労した。最終的にはgit-submoduleを使って実現したが、ディレクトリ構成の変更などを伴い苦労した。また、git自体の理解と習得に苦労した。 伊：プロプライエタリなVCSからの移行だったので、事例がない情報がないので苦労した。ツールを使っていたが、特定条件のリポジトリは必ず失敗する、などが起きて職人芸的にクリアせざるを得なかった。gitに理解のないエンジニアに移行を促す作業は、なかなか骨が折れた。今は古いVCSはシャットダウンできている。 さ：最初は特定プロジェクト向けにgitを導入したが、どんどん周囲のプロジェクトから手が挙がって利用者が増えた。当初はライセンスの購入が追いつかなかった。また、よりオープンに公開する文化にシフトするなかで、秘匿化しなければいけないトークンなどまでオープンにしてしまうことを防止したり、そういったポリシーを定めるのに苦労した。
２．いま時点の話 て：GHE導入して、何が変わりましたか？ 伊：一言で言うと文化が変わった。自分たちで調べてブランチ戦略を考えたり、勝手にPullRequestでコードレビューを始めたり、そういった変化が自然に起きた。 さ：各プロジェクトが自分たちで作っている製品を管理していたが、今は、チームを横断してPRを投げたりするような文化ができ始めている。良い変化だと思う。 井：様々なツールを見ていたのがGitHubに一本化されて効率があがった。またPRの時点で仕様や要求の共有ができるようになった。
て：GHEを管理していて困ったことは？ 伊：ソフトウェア的に問題が起きたことはない。Org/Teamの管理が自分自身でしかできない点が課題。 井：サーバ側でのトラブルはない。gitの勉強コストが困ることがある。git操作での事故がチラホラある。レビューを通すことが必須になったため、本流に入るまでの時間が長くなった部分もある。 さ：弊社はプライベートネットワークとパブリックネットワークが分かれており、それらのインターフェースを毎度設定する必要があり苦労している。今は解決している。
て：管理者からみてGHEのいいところは？ 井：安定しているサービスである。サポートが日本語で対応してくれるのも助かる。 さ：安定性はすごくありがたい。他に使っている他社製品はDockerベースのものが多いが、落ちたりバグったりする。管理者用のドキュメントも分かりやすくていい
て：ユーザの反応はどうですか？ 伊：良好。早く作業ができていい、という声を聞く。GHE内のすべてのコードを検索できるため、社内の特殊なノウハウを探して参考にしやすいのが嬉しい。 さ：使い出すと戻りたくない、という声が多い。 井：リポジトリをまたいだ検索はありがたい。使うべきではない関数の横断検索などは効率的にできた。
（オーディエンスから質問：福留さん）サーバの運用周りについて、手がかからないという話があったが、何か管理面で自動化の工夫をしている点があれば教えて欲しい。 さ：GHEはモニタリングでGraffanaが統合されているが、独自のモニタリングツールと統合したい場合に、モニタリングのAPIを使って情報を吸い出している。
て：これからGHEを導入したい人へのアドバイスは？ 井：PRは開発者にとって大きな変化なので、1つの最善の選択だと思う。 伊：競合製品と比べるのは良いと思うが、結局はGHEに辿り着くと思う。サポートのレスが早い。情報文献も多い。
会場風景
タイムテーブルとフロアマップ（今日はPegasusエリアを使わず）
このクッションを持ち帰りたかった
