GitLab Meetup Tokyo #12: 2018年振り返り - connpass

12月20日(木)に、「GitLab Meetup Tokyo #12: 2018年振り返り」に参加してきました。SNSシェア/ブログ枠で申し込んだため、感じたこと得たことを残しておきます。

参加目的

下記の内容に興味があったためです。

  • GitLabのユーザにはどんな人がいるのか、どんな人がGitLabを利用しているのか
  • 社内にGitLabを立てるにはどうすればよいか、どうやってCVS, SVNから移行していったか
  • GitLab x CI/CD、DevOpsと内部統制をどのようにして両立させているのか

Timetable

  • 三菱地所スポンサーご紹介
  • GitLab TokyoGitLab Tokyoのご紹介
  • Guenjun YooGitLab direction in 2019
  • @hiroponz 「GitLabとKubernetesではじめるAuto DevOps」
  • @tnirre 「cap of KubeCon+CloudNativeCon 2018 (GitLab Serverless)」
  • @jvasseur(LT) 「GitLabソースにコントリビュートしてみて勉強になったこと」
  • @xorphitus(LT) 「(仮) 独自パッチで進化させ過ぎたGitLabのOmnibus package移行」
  • grooves(LT) 「スポンサーLT」
  • @attakei(LT) 「GitLab-CI/CD+Pagesでポートフォリオを作ってみよう」
  • 全員忘年会・懇親会(ネットワーキング)

遅れての参加になってしまったので、前半はあまり話を聞けませんでしたが、メモ書きです。

GitLabとKubernetesではじめるAuto DevOps

Auto DevOps

  • .gitlab-ci.ymlの設定ファイルが不要。いい感じに自動設定してくれる
  • e.g. Auto Build, Auto Test ….
    • Auto Review Apps・・・Topic Branchを切ってMerge Requestを送った際にそのコードで
  • ただし、一部の機能は有料プランの加入が必須

GitLab + k8s

  • GitHub Runnerをk8sで並列実行させる。なるほど便利。

一時期、コンテナ技術の用語ぐらいはキャッチアップしたつもりだったが、今回の話の中でも、Service Mesh, IstioIngressなど概念を説明できない単語が出てきていた。もうちょっと追ってみたい。

recap of KubeCon+CloudNativeCon 2018 (GitLab Serverless)

  • AWS re:Invent 2018 でGitLabのAWSサポートが発表された
  • DevOps Tax ・・・各種ツールを繋げることでそれぞれの設定がつらい問題

CloudNativeという表現については、下記リンク参照。

クラウド・ネイティブ・コンピューティングを実現する技術要素 - コンテナー化 - 動的なオーケストレーション - マイクロサービス指向
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

(LT) GitLabソースにコントリビュートしてみて勉強になったこと

意識して良かった点

  • 小さなコミットを心がける
  • 毎回ローカルでRubcopを実行すること。 => Rubyのスタイル違反でビルドがこける
  • TDD
  • 迷ったら(困ったら)人に聞くこと(e.g. GitLabの中の人)

OSSのすごく良いところ

  • いろんなアドバイスをもらえる
  • 良いコードを書かざるを得ない環境
  • なによりもコントリビュートした達成感がある

実装には数時間だったが、Merge Request実施後、レビューとリファクタリングで10日間ぐらいかかったそう。

(LT) (仮) 独自パッチで進化させ過ぎたGitLabのOmnibus package移行

聞けば聞くほど、あー自分たちで運用したくないなぁという思いが出てきた。よっぽどコアな使い方をしない限り、サービスとして提供されるものを利用するのがよさそう。

(LT) GitLab-CI/CD+Pagesでポートフォリオを作ってみよう

  • kAZUYA tAKEI (@attakei) | Twitter 氏
  • GitHub Pages, Netlify, GitLab Pagesを比較したときのGitLabのメリットは、全てGitLabで完結すること
    • GitHub Pagesは、CI部分は受け持ってくれない
    • Netlifyは、Repositoryは管理してくれない
  • GitLab PagesでPortfolioを作成すれば、見る人からみれば、CI/CDの設定ができる人、静的ジェネレータなどを利用できる人、Gitを利用できる人など。ある程度、技術力のアピールにもなる

最近、NetlifyからGitHub Pagesに移行したところではあったのでかなり気になった。速度的に問題なさそうなら検討したい。

grooves(LT) スポンサーLT

Forkwellはエンジニアのアウトプットを応援する。

スポンサー費が1,000万円に達したそうです。

最近増田で日本人ITエンジニアの90%に記事を書いてほしくないというポストもあったという話もあったという話から始まったが、とはいえ「アウトプットは大事」という話の展開ではあった。

個人的にもアウトプットすることは重要だと思っており、アウトプットをなかなか出せていない自分自身にも危機感を覚えている。

最後に

GitLab Meetup Tokyoには初めて参加させていただきました。
主催者、設営の方々、参加者のみなさま、ありがとうございました。

Next Action

参考図書