読者です 読者をやめる 読者になる 読者になる

「GitLab LT」聴講レポート #gitlabjp

GitLabを利用したプロジェクト運営

自己紹介

  • @uchienneo

pixivisionの運用

運用方法

Board
  • 自由にレーンを増やせる
  • Issueとの同期はできていない
milestone
  • Issueとの同期は出来ている
  • 期日とかは表示できない
  • 今は自前でタイトルに書いて管理中
長所と短所
  • 開発が活発
  • Markdown記法なのが良い
  • スケジュールを立てたりは難しい

GitLab CIでDocker in docker

自己紹介

  • @jvasseur
  • 日本で12年ぐらい働いている

なぜdocker?

  • 同時実行することが多い
  • docker runnnerでええやん

問題点

  • hostのSELinux設定でコンフリクトの可能性
  • ビルドのcacheがされない→ビルドが長くなる
  • 無理やり実行すると破滅する

簡単なソリューション

  • DIDNをやめてshellを使おう
  • ただ、あまり推奨されない
    • セキュリティの問題とか

良いソリューション

  • Docker v1.13の–cache-fromオプションを使用する
  • 先に最新のイメージをpullしてから–cache-fromする。その後、pushする

Gitlabのバックアップについて

自己紹介

  • @Kirika_K2
  • 社内の開発基盤を見ている
  • GitLabはgitorius統合前から

スナップショットとは

LVMとは

  • 複数の物理ディスクをグループにまとめて論理ディスとして扱う方法
  • lvcreateで論理ボリューム単位でのスナップショットが取得できる
  • ボリュームグループに未使用の領域があること
  • unmountしてからlvconvert –mergeをすることでスナップショット時点に戻せる
  • PostgreSQLもバックアップを取得できる
  • 無停止するには、WOLというトランザクションログもバックアップする必要がある

メリデメ

  • 手軽なバックアプ手段として使える
  • 大量の差分があるとスナップショット領域があふれるかも
  • unmountする必要があるので無停止ができない

まとめ

  • LVMは世代別バックアップのような用途ではなく、静的な状態でバックアップを。

わりと大きい会社でGitLabをホスティングしてみた話

発表資料

www.slideshare.net

自己紹介

  • @jeffi7
  • 社内の開発部門向けにサービスを提供

GitLab前夜s

  • 偉い人からOSSを使った開発環境を作れと言われた

GitLabへの道

  • チームメンバーがGitLabが良いと言ったのでGitLabにした
    • チームメンバーには従いましょう(MGRへ)

救世主現る

  • Docker Version1.0が出た
  • GitLabのイメージが出た

システム構成

  • nginxを加えた以外はシンプルな構成
  • worm stanby
  • PosgreSQLに乗り換えようとしている

トラブル

  • CIのbuild詳細が重い
    • CPUが100%で張り付いていた
  • 10〜70回/分リロードしていた
    • Prometheusを運用中

悩ましいこと

  • 深化早すぎ
  • 部分的にスケールアウトしづらい

これから

  • 楽してDevOpsしたい
  • issueを上げているが、MRを出したい

野望

  • GitLabをもっと流行らせたい
  • Githubを使いたい派が多いけど、社内で使うにはGitLabで
  • DBをぶっ壊しても責められない組織風土が良い
  • 「もしかして:Github」をなくしたい

「ここがすごいよGitLab CI」聴講レポート #gitlabjp

発表資料

ここがすごいよGitLab CI #gitlabjp

自己紹介

  • @sue445
  • ドリコム
  • 絶対にフォローしないで下さい!

GitLab関連でも色々と作成した

  • gitlab_awesome_releaseとか作成

ドリコムとGitLab

ジョブの記述方法

  • yamlだけでスッキリ書ける
  • 2つ以上のジョブの合流もできる
  • 複数のDocker fileを1つのyamlファイルに記載できる
  • 画面でポチる必要があるのが難点
  • ビルドパラメータの軸が2つ以上ある場合は難しい

「GitLabコミュニティへのコントリビュート」聴講レポート #gitlabjp

発表資料

docs.google.com

自己紹介

  • @hiroponz
  • (株)ルビー開発
  • 勤務地は仙台
  • 今日はこれのために出張してきた

GitHubとの違い

  • GitLab ECは開発に参加できる!

類似のOSSとの違い

  • 似たようなものがあるが、それぞれ開発言語が違う
  • 開発リソースが違う
  • マシンスペック
    • 他よりもマシンスペックをくう
      • Gogs < GitBucket < GitLab
  • 大規模利用
    • GitLabはGitLab.comで利用されているので、スペックを上げれば大丈夫(数千人単位も可能)

コントリビュートの話

  • ソースコードの修正
    • 今回メインで話す
  • ドキュメントの整備
    • タイポ直し
  • バグ報告
    • twitterで文句を言ってないで
  • 新機能の提案

きっかけ

  • 前職でGitLabを導入したらバグを踏んだ
    • ShiftJISのバグ
  • わかりそうだったので修正してPRを投稿
  • すんなりマージされた
    • You are Welcome!

わーい、たのしー

  • いっぱいPRを出した
  • GitLab MVPに選ばれた
  • 毎月22日に新バージョンがリリースされる
  • 各リリースのブログポストで発表される
  • 基本的には栄誉賞

コントリビュートのメリット

  • GitLabが便利になる
  • 効果的な使用方法を学べる

GitLabが便利になる

  • 仕事の効率が上がる
  • EEに追加予定の機能をCEにも追加できる
    • EEのissueで見て、実装してCEにMRを送れば良い
    • EEに追加された後のMRはリジェクトされる
  • 社内のGitLabを魔改造しなくてよい
    • GitLabはVerUpのサイクルが早いので辛くなる

GitLabの効果的な使用方法を学べる

  • GitLab社自身がヘビーユーザー
    • 使い方を学べる
    • リリースサイクルの仕方とか
    • 6000を超えるissueの捌き方
      • 多分捌けてない
    • 高速な機能追加の実現方法
  • 開発者間のコラボレーションを眺められる
    • GitLab社はフルリモートチーム
    • 効果的なコードレビューの方法

実践的なRailsの開発知識が身につく

  • Gem fileの参考
  • メンテナンスしやすいコードの書き方
    • コミットログを眺めるだけでも学べる
  • テストコードを書くことをルールとしている
  • 比較的モダンなJS開発ができる

英語でのコミュニケーション能力が身につく

  • ソフトウェア開発の共通言語
  • 応用範囲が広い
  • キャリアにも繋がる

その他諸々

  • 転職の時にプラス
  • 執筆依頼が来る
  • スピーカー依頼が来る

コントリビュートの方法

  • ガイドラインを熟読して下さい
    • 3回ぐらい読めばなんとなく分かる
  • Community Contributionのラベルを貼られた他人のMRを参考にする
    • 社員以外の人

マージされやすくなるポイント

  • Issueがあるかどうか
    • なければ起票してから
  • バグ修正の方がマージされやすい
  • 機能追加の場合、簡単なテストを追加する
    • 1個の正常系のテストだけでも良いので…
  • UIの修正の場合、修正前後のスクリーンショットを貼る
  • パフォーマンスの場合はベンチマークの結果を載せる

注意点

  • DBマイグレーションが必要な場合はダウンタイムを発生させないようにする
    • カラム削除とか
  • パフォーマンスを著しく悪化させない
    • アクセスを著しく増加させるのはNG
  • コードのライセンス
    • CEのマージはEEのマージもされるので、商用利用を認めていないのはNG
    • 機械翻訳のコピペはNG
      • 近々多言語対応されそう
  • 礼儀正しく

英語の壁

  • 高校レベルの英語でもOK
  • 分からなかったらGoogle翻訳
    • 相手も慣れてる
  • GitLab社社員は親切

GitLabIssueBash

「GitLabの実践的な運用」聴講レポート #gitlabjp

資料

qiita.com

自己紹介

  • @catatsuy
  • 会社のアドベントカレンダーで運用方法を公開した
  • Pixivで働いている

  • 個人的には、以前のJTF2015で登壇している印象が強いです。

nihonbuson.hatenadiary.jp

GitLabのインストール

  • インストールはそんなに難しくない

セットアップサーバについて

  • グローバルIPを持つサーバー上に立てることが前提
  • サーバーは1台であることが前提
  • 複数台構成は現実的ではない
    • DBは別IPでもOK

GitLab.comのバックアップ体制

  • 今回問題になったのはあくまでもGitLab.comの問題

GitLabの持っているデータ

  • Radisは最悪吹っ飛んでも問題ない
    • セッションとかキャッシュしか持ってない

GitLabのデータベース

RailsMySQL

  • MySQLの知見がない限りMySQLを使わないほうが良い
    • ハハパパ問題とか

GitLabのバックアップ

  • bundle exec rake gitlab:backup:createでバックアップできる
    • git db create はmysqldumpとかをしているだけ
    • git bumdle createを叩いて保存しているだけ
    • git upload create はファイルをコピーしてtarで固めているだけ
  • 最終的には1つのtarファイルに纏められる
  • 様々なサーバにバックアップファイルを送ることも可能
    • cronしたり
      • 環境変数でcron=1を設定するとエラーしていない場合にログ出力しないことが可能

MySQLのバックアップ

  • dump以外にも、停止してdata_dirをコピーしたりする手段がある
  • リストアも可能

バージョンアップ

  • バージョンアップにはDBのバックアップを録るように書かれている
  • GitLabのバージョンアップで関わるのはDBぐらい
  • 一気にVerUpを上げることも可能
  • 一部、特殊な作業が必要

無停止VerUp

  • ほぼ無理
  • master,slaveでも可能だが手間がかかる
  • アプリケーション起動中に行うことはできない
  • ある程度短くすることは可能だがrakeの時は停止する必要あり

最後に

  • ソースコードもシンプルなので動きを追うことは比較的容易
  • 昔はGHEと呼ばれた時代もあったが、ソースコード公開によるメリットが大きい

「GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開」聴講レポート #gitlabjp

発表資料

qiita.com

自己紹介

  • @tnir
  • Takuya Noguchi
  • Git利用歴10年
  • GitLabはパブリック公開した日から使っていた
  • 所属していた会社で2013年から使っていた
  • 2014年から管理者として利用
  • 2015年からはGitlab.comの混んとりビューア

なぜMeetupを開くのか

  • 日本語の情報がなかったから
    • あっても古い
  • Gitlab.comが話題になったから…ではなく、準備していたら事件が起きた

GitLab.JP

  • 仙台で発足して、3,4回やっていた
  • 鹿児島でも勉強会が開催されていた
  • 東京でもやろう

よく聞くGitLabのイメージ

  • インストールが大変
  • ウェブアプリが遅い
  • GitLab.comでデータがロストした

GitLabの歴史

  • GitLabは後発のサービス
    • 後発の製品でどうやって優位性を持たせるか

GitLab.comの競合

  • GitHub + ecosystem
  • BitBukket + ecosystem

GitLab CE/EEの競合

  • GitHub Enterprise
  • GitBucket
  • Gogs
    • GO言語で出来ている

GitLab CE/EE

  • RailsベースのソースではGitHubの中でスターが一番だった(2016年)

4種のGitLab

  • CE
    • 一番ユーザーが多い
  • EE
    • 有償版
  • .com
  • GitHust.io
    • Saasではなくプライベートで運用したい
    • デジタルオーシャン上で
    • アップグレードやセキュリティを担保
    • $80/月

GitLabマイルストーン

  • 半年ごとにVerUpしていた
  • Ver6からは1年半に1回ぐらいのVerUp頻度
  • 現在はVer8
  • その間に4回資金調達して40億円調達した
  • 3/22のVer9が出る

2016年を振り返る

  • 8.4〜8.15をメジャーリリース
  • 機能がどんどん追加されて

パフォーマンス面

  • 2014から2015年あたりにパフォーマンス劣化が著しくなった
  • 2016年はパフォーマンス改善した
    • 1月にInfluxDBを利用したモニタリング開始
    • 後半はPrometheus導入

管理面

  • omnibus-gitlabが一番手軽なインストール
    • 色々な個人ブログではソースでのインストールも書かれているけど、オススメしない
  • Dockerでもサポート
    • まだまだ巨大なイメージなので、デフォルトの状態だときついかも

PostgreSQL

  • 登壇する人はMySQLユーザーが多いみたい

Radis

  • 現在、2.8から3.2に上げるMRを出しているところ

コンテナレジストリ

  • これもGitLabが提供している

モニタリング

  • 改善はしているがGithub.comに比べるといまいちな部分も

Docs

  • ドキュメント大事
  • docs.gitlab.comがリニューアルされた
  • 英語さえできれば貢献は可能

開発

  • OSSなのでGitLab.com上でコントリビュート可能
  • 日本人は少なそう
  • GitLab Development Kitで簡単に構築可能

Backend

  • 普通のRailsアプリだが、一部GOで書かれている

Frontend

  • jqueryが多い
  • テストはJasmine+Karma

UI/UX

  • 最初はデザイナーが少なかったが、最近増えた
  • GL社員がちょっと多すぎる気がする

パッケージング

  • chef/omnibusパッケージを使用している

コミット以外の貢献方法

  • イイねを押すことも貢献の一つ
  • GitLab Pagesもいいねが100を超えて実現した

個人的な野望

  • Cloud-native
  • Server-less
    • 現状だと難しいかも

250人のチームで運用してみてわかったこと

  • Gitの習熟度がバラバラ
  • 高品質化のためにトレーニングが有効的
    • GitLab Docsが有効
    • ただし日本語訳がない

バグフィックス

  • 昼、起票
  • 夜、修正
  • 時差があるので、夜活動が他国の人にとって良いみたい

今後に向けて

  • 組織の方針とGitLab.incの方針(技術選択)が合致したのでうまくやってこれた。
  • 組織毎に主体的な開発戦略が必要

今日伝えたかったこと

  • かなり改善されてきた
  • OSSに貢献してよりよいツール・プラットフォームを使いましょう
    • 社内でパッチを当てるとかではなくMRを!

宣伝

  • 第2回を開催決定しました。
  • 4/11にリクルートでやります!

WACATE 2016夏 ~走りきるテスト設計~ #WACATE

wacate 技術 勉強会

昨年、WACATE 2016夏に参加してきました。

今回は1つの題材を元に、テスト分析・テスト設計を行おうという趣旨のものでした。

WACATE2016のワークで行ったことを共有したいと思います。

テスト分析

最初に仕様書、設計書が配布されたところで、

  1. 個人ワーク
  2. ワーク結果をマージ(基準にできそうな人のワーク結果を土台にグループとしての分析結果を出す)
  3. 各テスト条件に対して、利用できそうなテスト設計技法を選ぶ

という計画を示されました。

私の班が行ったこと

自分達の班は、個人ワークおよびマージした後、

  • 「本当にお客さんが要望していることってなんだろう?」
  • 「新業務がきちんと行うことができることではないか?」

という結論になり、業務を回すために必要なことは何かということを中心にもう一度個人ワークをすることになりました。

個人的な想い

上記の議論の際、「業務を回すこと」ではなく「一つ一つのチェックがしっかりできること」という結論に持っていくことも可能であり、そちらを取ったほうが色々なテスト技法に触れられるのでは?と思っていました。

しかし、班としての結論・納得は「業務を回すこと」であり、私自身もそちらで納得できたので、この方向で進めました。

ただ、正直、今回のワークとして成功できるのか、そして初参加の方に満足してもらってWACATEを終わらせることができるのか、この時点ではすごい不安でした。

秋山先生の講演

2日目の朝は、秋山先生の講演がありました。

その中で、分解という部分に注目し、前日に出てきた内容についてグループ化を行うことにしました。

発表スライド

www.slideshare.net

個人的な感想

分解、そしてセミラティスの話とか、JaSST'16 Tohokuでの話と似ているなと感じました。

実際、グループ化の作業は正にJaSST'16 Tohokuと同じようなワークになりました。

テスト設計技法の実践&テストケースの作成

私達の班では、以下の4つを利用することに。

特に、「業務を回すこと」を第一に考えることにしたので、ユースケーステストの作成に3人を投入し、残りの部分に、1人ずつ分担して作成することに。

結果的に、この方針が良かった(気がする)。

ユースケーステストはベテラン1人が若手2人をサポート。

同値分割の人はすぐに終わったので、状態遷移を作っている初参加の人をサポート。

同値分割&デシジョンテーブル担当は黙々と実施。

そんな形で行いました。

ただし、テストケースについては、時間切れで最後まで完成できず・・・。

そこまで考慮した時間配分にできればもっと良かったかなと。

個人的な想い

ユースケーステストは、他のテスト技法に比べても、作成者の差が顕著に出やすいものになると思っています。

今回も作成した3人で差が出ました。

ただし、今回はベテランではない人のテスト設計結果を採用しました。

これは2つの狙いがありました。

  1. 今の自分達チームの結果をきちんと示したい(ベテランの内容をそのまま使ってしまうと、「自分のチームの成果」という意義が薄れてしまう)

  2. テスト設計結果の抜け漏れの部分を、他の設計したもので補完できていることを示したい。

特に2つ目の狙いは、ユースケーステストで書ききれなかったケースを、状態遷移側で上手く補完できました。

成果物

以下の写真のようになりました。

全体の進め方

f:id:nihonbuson:20160622224028j:plain

業務フロー

f:id:nihonbuson:20160622224039j:plain

テスト分析結果

f:id:nihonbuson:20160622224048j:plain

ユースケーステスト

f:id:nihonbuson:20160622224056j:plain

f:id:nihonbuson:20160622224103j:plain

ユースケーステストから作成したテストケース

f:id:nihonbuson:20160622224114j:plain

状態遷移

f:id:nihonbuson:20160622224122j:plain

同値分割・境界値分析

f:id:nihonbuson:20160622224127j:plain

デシジョンテーブル

f:id:nihonbuson:20160622224133j:plain

デシジョンテーブルを元にしたテストケース

f:id:nihonbuson:20160622224139j:plain

はっきり言って、成果物は他の班よりも綺麗ではありません。

しかし、班の人全員が納得できるものになったのではないかと感じています。

最後に

2017年夏のWACATEは6/17・18開催予定です! wacate.jp

JaSST'17 Tokyoに行ってきました #JaSST

先日、JaSSTに行ってきたので、その参加レポートを書きました。

軽く感想を書きつつ参加レポートを紹介します。

基調講演

nihonbuson.hatenadiary.jp

  • 裏話がいっぱいで楽しんで聞くことが出来ました。

  • そして、国際標準を決めるって大変と感じ、SQuaREって良いものだと再認識しました。

招待講演

nihonbuson.hatenadiary.jp

  • 奈良さんのぶっちゃけトークがすごい面白かったです。

楽天トラベルの開発プロセスに関して

nihonbuson.hatenadiary.jp

  • プロセス改善の例として参考になりました。

  • 他のセッションもそうだけど、如何にしてVモデルでいう左側に関わっていけるのかをテーマにした話が多かった気がします。

【ジャストーーーク】転職芸人が語るテスト/QA技術者としてのキャリアパス

nihonbuson.hatenadiary.jp

  • 登壇者は転職芸人という立ち位置で参加していましたが、転職するかどうかは関係なく、テストエンジニアとしてどうしていくのかということに関して参考になりました。

教科書に載らないテストマネジメント

nihonbuson.hatenadiary.jp

  • テストマネージャとしてあるべき姿をぶっちゃけトークで話していました。

  • 途中参加だったのが悔やまれるぐらい、すごい良いセッションでした。

テスト現場のお悩み相談

nihonbuson.hatenadiary.jp

  • あるあるな事例に対して、様々なアプローチでアドバイスしていました。

  • もはやテストの範疇を超えて、設計段階の所からどうしていくかみたいな話もありました。

Web.JaSST Web Service QA Meeting in JaSST'17 Tokyo

nihonbuson.hatenadiary.jp

  • 様々な企業での事例を話していました。

  • 目的を持ってQA活動をしているところが多い印象を持ちました。