JaSST'17 Tohoku 基調講演「テストの極みを目指して 〜さあ、理想に近づくための一歩を踏みだそう!〜」聴講レポート #jassttohoku

発表資料

www.slideshare.net

今回の発表の目的

  • 自分自身がテストオペレーターからテスト設計者にステップアップするための方法
    • 今日のJaSSTの参加者がみんなベテランやん!
  • 自分の後に続く人に伝えてあげる方法

改めてソフトウェアテストについて考えてみる

  • テストってなんですか?
    • 背景によって色々異なる
    • JSTQB用語集などが参考になる…けど分かりづらい
    • 『ソフトウェア技法』よりテスト担当者の精神面による区分を引用
      • 成熟度によって異なる
        • フェーズ1「テストとは動くことを示すものである」だと、テストをして何が嬉しいの?と思われがち
        • フェーズ4まで行くと「テストは欠陥予防である」
      • にしさんが「テスト道」として伝えることが多い
    • 山崎さんの言葉でいうと「テストとは品質に関わる"新たな"情報を提供するための活動」

テストの価値は情報提供の価値

  • 早い・安い・旨い
    • 早い…CIで行うことで、すぐにフィードバックがくる
      • 3日後の自分は他人である
      • リスクの高いものは早めにやることで改善できる
    • 安い
    • 旨い…有益な情報でなければならない
      • 作業をこなすことは意味がない。せっかくやった結果がうまく活用されない
      • テスト結果がわかり易いほど価値が高くなる

山崎さんがモヤモヤしていること

  • デベロッパー=開発の専門家
  • アーキテクト=アーキテクチャの専門家
  • テスター=テスト実行者≠テストの専門家
    • JSTQBでは、テストの専門家として定義している

なぜテスター≠テストの専門家と認知されないのか

  • テストに対して理解されていない
  • そもそもテストの専門家以外もやってる?
    • テストをする人がテスターだけでなく、ユーザーだったりする
  • 他の専門職と比較してスコープが広いから?
    • V字モデルの右側すべてが「テスト」ですからね。

理想のテスターとは?

  • 良いテストエンジニアとは?
  • JaSST'14 Tokyoの基調講演より(Stuart Readさん)
    • TEST SKILLS
    • IT SKILLS
      • インフラの知識とかも必要
    • DOMAIN KNOWLEDGE
      • ドメイン固有の情報
      • 満たさなければならない要件とか
    • SOFT SKILLS
      • トレーニングしても身につき難いもの
      • 例えばコミュニケーションモデルとか
        • 正しかったとしても、それをきちんと伝えていなければ意味がない
    • この4つをバランス良く習得しているのがProfessional Tester's Skill-space
    • 「テスターだからプログラミングはしません」は残念なこと。価値として提供できない

開発を加速させるための協力者というマインド

  • テストは基本的にテストそのものが目的ではなく手段である。
    • テストが安定してない→バグが出ている状態
    • そんなネガティブなことを伝えても加速しない
  • テストをゲーティング(これを通らないと先に進ませないよ)とならないように
  • 開発と対立関係ではなく協力関係にならないといけない

最初の一歩を踏み出すのに重要な3つのこと

  • テストの全体観を持つ
  • ロールモデルを見いだす
  • 成長へのモチベーションを持ち続ける
    • 動機づけしてない人に伝えても暖簾に腕押し状態

1.テストの全体観を持つ

  • テストの全体観を保つための3つの軸
    • テストレベル
    • テストタイプ
    • テストプロセス
  • この3つを理解していると非常に理解しやすくなる
  • ドラクエ1の松明のようなもの

テストレベル

テストタイプ

  • 以下のようなテストタイプがある
    • 機能テスト
    • 非機能テスト
    • 構造テスト
    • 変更部分のテスト
  • テストオペレータに何のテストタイプを行わせているのか理解していますか?

テストプロセス

  • 普通の開発プロセスと同じように、テストにおいてもプロセスがある
    • テスト計画
    • テスト分析
      • どんなテストをしなくちゃいけないのか
    • テスト設計
      • どんなテストケースを作ればよいのか
    • テスト実装
      • 実際にテストケースを作成する
    • テスト実行
    • 終了基準の評価とレポート
    • テスト終了作業
    • モニタリングおよびコントロール
  • テスト実行しか見えていないと、テスト分析とかに意識がいかない
テストケースを作るまでのイメージを持てることが重要
  • テスト設計技法は学ぶが、それを上手く使えない…
    • テストベースに対していきなりテスト設計技法を適用しているのでは?
テスト開発プロセスの例
  • 文書
  • →テスト分析してテスト設計仕様を作る
  • →テスト設計してテストケース仕様を作る
  • →テスト実装することでテスト手順仕様が作られる
    • マニュアルでなければテストスクリプトになったりする
  • 29119-2では、テスト条件とテストケースの間にテストカバレッジアイテムがあったりする
  • どうしてこのテストケースにしたの?という質問に答えられないといけない
    • 「なんとなくテストしたらバグが発見できませんでした」だと情報が少ない
テスト要求分析の例
  • 何をテストしなければならないのかをきちんと洗い出すのがテスト要求分析の一側面
テストアーキテクチャ設計の例
  • 導出したテスト観点から関連性を見出してテストフレームを定義したり、
  • 複数のテスト観点やテストフレームをまとめてテストコンテナを作ったり
    • 例えば、相互互換性のテストではOSとかブラウザとかのテストフレームがあり、それをまとめて「相互互換性」とするのをテストコンテナを作る
  • 「テストの十分性や妥当性の教えて欲しい」とよく言われる
    • 全数テストはできないので、サンプリングしないといけない
    • ステークホルダーと合意を取らないといけない
    • 合意を取るためにテスト要求分析をしたりテストアーキテクチャ設計をしたりする
テスト詳細設計の例
  • 網羅基準とかコンテキストを元にテストケースを導出する
  • これらのプロセスの最後で初めてテスト設計技法が使われる

2.ロールモデルを見出す

大まかな志向の方向性を意識しよう

  • ロールモデルは会社の人事制度とも関わるが、大きく分けると以下の2つ
    • 技術トラック
    • マネジメントトラック
      • 偉くなるためにはマネジメントトラックしかない会社の場合、自分がパイオニアになって技術トラックの方向性を作る必要がある

ISTQBより

具体的にイメージできる憧れの人を持とう

  • 可能であれば社内の人
    • コミュニケーションが取りやすいから
  • 走り出したばかりの人が「俺は海賊王になる!」と言ったら…
    • →どうやって?実現性が分からない

自分の志向する方向性を探してみよう

  • セルフデベロップメントプランを作ってみよう
    • どうやって極みを目指すか?
    • 目指すべき理想の姿において、1年後の自分・10年後の自分…などを具体的に描いてみよう
    • ある時点での姿に対して、「どのような姿か」「その姿になるためにはどうすればよいか?」を書いてみる
      • どんどん具体的に落とし込むことで、今の姿に近づいていく(半年後→1ヶ月後→2週間後)
    • 自分自身で壁を作って成長を限ってはいけない
      • そんな壁は壊してしまえ

3.成長へのモチベーションを持ち続ける

  • 成長が目に見える形で測れて実感できることが大事
  • 既存のツールを使ってみたり…
    • テストにおいてはTest.SSF(Skill standard Framework)があったりする
    • テストに限らなければITSSとかETSSとか。
    • テストの全体観が無いとそもそも測れない
  • 資格試験も自分の成長を感じられる一つの尺度
    • ただ、単調に行い続けるのが大変

ぜひ社外に飛び出してみよう!

  • 社外活動による知見・刺激は多いはず
    • JaSST
    • WACATE
    • SQiP
    • テスト設計コンテスト
  • いずれは参加者から運営側になろう
    • 社外活動に関わると今まで得られなかった情報量が増える
    • そのまま社内に適用するとうまくいかなくなる
    • うちの会社の人は分かってねぇ!という麻疹になったりする
      • 「そうじゃないんだよ」と諭してあげよう

感想

  • 「テストの全体観」ってどれだけの人が持っているんだろう…?
  • 成長へのモチベーションとして書かれている「社外に飛び出す」のきっかけの作り方(与え方)が難しいなと感じた。
  • 理想のテスターがもっともっと出てきてほしい!

#ICST2017 に参加してきました!

すごく今更感がありますが、ソフトウェアテストの世界最高峰の国際カンファレンスであるICST2017に参加してきました!

ICST2017の公式ページ(日本語版)

ICST 2017 | ICST2017のページへようこそ!

私が参加したセッションを紹介し、簡単な感想を書きます。

1日目

基調講演「The State of Continuous Integration Testing at Google. 」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

Non-Semantics-Preserving Transformations For Higher-Coverage Test Generation Using Symbolic Execution

  • 実践的なプログラムコードに対してどのように単純化し、最適なテストケースを作成すれば良いかということを考えた研究でした。

Uncertainty-Driven Black-Box Test Data Generation

  • あるプロダクトコードに対してテストケースをランダムに選択するのではなく、機械学習を用いてもっと効果的なテストを選択できないかという研究でした。

Automated Test Generation and Mutation Testing for Alloy

  • テストケースを生成する際に、カバレッジを気にしながらテストケース生成する方法があるが、それ以外にミューテーションで破壊されるようなテストケースを生成し、そのテストケースの有効性を確認した研究でした。

NIVAnalyzer: a Tool for Automatically Detecting and Verifying Next-Intent Vulnerabilities in Android Apps

  • セキュリティ的に脆弱性のあるプログラムコードを検知する仕組みを作成し、既に公開されているAndroidアプリについて脆弱性が無いか確認した研究でした。

Efficient Safety Proofs for Industry-Scale Code using Abstractions and Bounded Model Checking

  • この発表はあまり理解出来なかったです…。

System Testing of Timing Requirements based on Use Cases and Timed Automata

  • タイミングが関わる機能のテストについて、状態遷移に工夫をすることで、より有効的なテストケースを生成するという研究でした。

A Comparative Study of Manual and Automated Testing for Industrial Control Software

  • 同じ製品に対し、自動テスト生成と手動テスト生成を行って、カバレッジやミューテーションがどのように違ったのか比較した研究でした。

How Do Assertions Impact Coverage-based Test-Suite Reduction?

  • 一般的にはテストカバレッジを気にしてテストケースの削減を行っているが、Assertionを気にしてテストケース削減を行ってみた研究でした。

Automata Language Equivalence vs. Simulations for Model-based Mutant Equivalence: An Empirical Evaluation

  • ミューテーション、ランダム、ユースケースからのそれぞれのテストケース作成に対して、強度なミューテーションが発生した場合に検出が出来るのかという研究でした。

2日目

基調講演「Testing and Validation Requirements for Automated Driving Technology.」

  • 自動運転についてトヨタの方が発表しました。
  • トヨタがどのような考えを持って研究しているのか、どのような最新の研究が行われているのか発表していました。

Perphecy: Performance Regression Test Selection Made Simple but Effective

  • パフォーマンステストの回帰テスト方法について提案した研究でした。

A Selection Method for Black Box Regression Testing with a Statistically Defined Quality Level

  • 過去の故障確率に基づいたテストケースの選択方法を提案した研究でした。

Private API Access and Functional Mocking in Automated Unit Test Generation

  • プライベートメソッドに対しての単体テストを上手く行う方法を提案した研究でした。

Using Semantic Similarity in Crawling-based Web Application Testing

  • 自動テストで用いられるDOM要素をベクトル化して、機械学習でどのような値が入るのか自動的に判別するという方法を提案した研究でした。

Barista: A Technique for Recording, Encoding, and Running Platform Independent Android Tests

  • Androidテストを行うツール Baristaの紹介とその効果の検証についての発表でした。

ATOM: Automatic Maintenance of GUI Test Scripts for Evolving Mobile Applications

  • Versionがどんどん更新されていくようなツールに対してのGUIテストのアプローチの提案をしていた研究でした。
  • 状態遷移図を描けば、振る舞いが大きく変わらない状態ならば対応できるはずだ、みたいなことを言ってた。

Transferring State-of-the-art Immutability Analyses: Experimentation Toolbox and Accuracy Benchmark

  • 正直、よく覚えてない…

Accelerating Test Automation through a Domain Specific Language

  • GebやSelenideといったSeleniumラッパー系のツールATAPの紹介
  • eclipse上でサジェストが出るのが特徴
  • 休憩中、発表者に色々と質問した。

Taming Coverage Criteria Heterogeneity with LTest

  • 一つ前の発表の内容ばかり考えててあまり覚えておらず…。

3日目

基調講演「Model-Based Testing and Model Inference: Better Together!」

  • モデルベーステストのお話
  • テスト設計も自動化出来るという夢のあるお話だったが、イマイチ自分の言葉には咀嚼できず…。

Are there any Unit Tests? An Empirical Study on Unit Testing in Open Source Python Projects

  • Pythonで書かれたコードのテストがISTQBで定義されている単体テストになっているか調べた。
  • 調べ方は、テストコードが1つのimportだけを読み込んでいるかどうかで判断した。
  • 疑問点が一つあったから発表者に質問した。

パネルディスカッション「Bleeding-Edge Testing Challenges that the Software Industry Faces - an Invitation to Researchers to Address these Challenges」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

パネルディスカッション「Quality and testing in Software Engineering curriculum」

  • 聴講レポートと感想はこちらの記事を見てください

nihonbuson.hatenadiary.jp

全体的な感想

色々と社内、国内だけでは知り得なかったことが感じ取れて本当に良かったです。

おまけ

  • 朝食(毎日バイキング形式で提供されてた)

f:id:nihonbuson:20170412004012p:plain

  • 1日目の夕食(立食形式)

f:id:nihonbuson:20170412004025p:plain

f:id:nihonbuson:20170412004033p:plain

これらも参加費にコミコミでした。

#ICST2017 基調講演「The State of Continuous Integration Testing at Google」聴講レポート

はじめに

  • ICST2017の中で、「The State of Continuous Integration Testing at Google」というタイトルでGoogleのエンジニアであるJohn Miccoさんが基調講演を行いました。

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation

発表スライド

http://aster.or.jp/conference/icst2017/program/jmicco-keynote.pdf

今日話すこと

  • Googleのテストの状況を話す
  • 開発者が3万人頑張っている

Googleについて

  • 420万のテストケースが継続的に動いている
  • 1億5千万のテストケースが動いている
  • ほぼ全てが自動化されている
  • Googleは自動テストが好き
  • 開発者はテストに時間をかけられません
  • 1万3千行のプロジェクトチームがある
  • 99%がテストに合格している
    • 失敗することはたまにある

テスト文化について

  • 自動化テストを促進する文化がある
  • 10年の文化がある
  • コードビューがある
  • テストの経験についても話し合う
  • Googleの新入社員に対してテストの仕方を教える
  • SETIでテストについて教えている
  • コードビューでモニターしている
  • チームに取り込まれているプラクティスを行う
  • 他にも色々行われている
  • 420万のテストは開発者が行っている

回帰テスト

  • 1つのbranchで何十億ものコードがある
  • それを3万人の開発者がテストをする
  • どの回帰テストをするのかの選択が大切
  • 例えばfoo.hを選んだ場合は赤部分のところをテストする(スライド5ページ)
  • 選択が適切にできればスケジュール化しなくても良くなる
  • クレームから状況を解析して行う
  • 1秒間に変更を2つ行うとBackendが追いついていかなくなる

Presubmit testing

  • 粒度の細かい従属性について見ていく
  • 同じプールを使って
  • Presubmit testを上手く使ってコミットを行う
  • コードビューツールがテスト結果を検知して却下したりする
  • 開発者の判断ミスによって壊れないようにする

Postsubmit testing

  • リグレッションテストが上手く行っても、それでOKではない
  • テストの優先順位は付けない
    • 時間がかかるし
  • なるべく並列に行う
  • Backendとしてキャパシティがあるか確認する
  • スケジューリングの場合、どこかが空かないとやれないから
  • passしたらflagをたてて変更を書ける
  • 2年間のテスト結果やコンソールログを保存している(DBに入れている)
    • どのようなファイルのエディットをしたかなど

グラフ

  • チャンジリストを表している(スライド10ページ)
  • 横軸が時間、縦軸が個々のテストを表現している
  • グラフの1つ目の縦軸は回帰テストを4つ行うことを表している
  • 今までの変更を見て、マイルストーンを引いて、多くのテストのトリガーを引くことになる
  • キャパシティが溜まった時にテストが行われる
  • 45分間ごとにテストを実行される
  • 1日1回45分ぐらいで行われる
  • 最も直近で影響を受けた変更を探し出す(スライド11ページ)
  • きちんと順番通りになっていない可能性もある(スライド12ページ)
  • これをDBに入れて、どれがGreenなのか探す
  • 失敗した場合、何が原因で失敗だったのかを明らかにする(スライド14ページ)
  • どの変更がBreakしたのか判断する必要がある
  • 回帰試験のセレクションをして、スケジューラが必要になる
  • これを塊にしなければならない
  • キューに入れてバッチに入れる
  • もしある特定のシステムが受けた場合、システムのものなのかユーザーのものなのか明らかにする
  • ツールが失敗した場合は再実行を行う
  • 開発者のサブミッションと合格・不合格の判断をなるべく速くする
  • マイクロスケジューリング
  • 原因がどこにあるのか
  • ケースのリストアップをしていく
  • ギャップを埋めていく
  • 開発者が破壊する恐れがある
  • 限られたリソースで済むようにする
  • 破壊実験をしていく

Flaky(スライド21ページ)

  • あてにならないテストのこと。
  • コード以外のものには従属していない
  • テストのアイソレート化、切り分けが必要
  • 全体の16%はFlakyである
  • プロダクトのリリースをブロックすることが多い
    • 全てのパスしなければいけない
  • 16%はいつかFlakyになる
    • 全体で1万近くのテストがあるので1000近くある
  • 何か問題があるとFlakyだから、となってしまう
  • 2%〜16%はFlakyテストを再送されることになる
  • このFlakによって赤信号になってしまう
  • マイクロスケジューラだとパスするかなと思うかもしれないが、緑にするためには、Flakyもクリアする必要になる
  • プロダクションコストに関してはフレーキになる
  • どのくらいのコストがFlakyにかけてしまうのか

  • 何が原因なのか

  • テスト実行の1.5%がFlakyの継続率になる

    • これをFixさせないといけない
      • Fixさせるのは時間がかかる
  • Flakynessを緩和しないといけない

システム

  • Flaky testを認識する
  • failedになると、Flakyになるか確認する
  • 10回それを走らせてFlakyであると判断する
  • スタックトレースもDBに保存する
  • Flakynessレベルに変更になる。(1%のFlaky率から5%のFlaky率に変更など)
  • 自動テストをして、Flaky状態も管理する
    • 例えば、50%のFlakyになるGmailは上手くいかないだろう、とか

OSS

  • Bazelなどのように、OSS化して公開しているものもある(Bazel.io)

学会のリサーチについて

  • OSSプロジェクトのものに対して仮説をたてる
    • 実用性には欠ける
  • Sponser resercherの方々や学生に協力を頂いて、データセットのペーパーを出している
  • Googleコードベースも仮説をたてている
  • 1つのテストがFailになった時に何が原因なのか調査している
  • 1億5000万のテストの結果をOpenにしている
  • 業界と学会のコラボレーションで解決ができるはず
  • API frameworkも作成している
  • かなりのビジネスチャンスがある
  • インターンシップもある
  • journal clubに参加すると、月刊誌をお送りする

質問

3rdPartyについて

  • 異なる言語の自動化をどのように行っているのか
  • また、テストコードと開発コードを同じ言語ですべきか
  • 他の言語で書くこともできるが、枠組みとしては同じ言語で行う
  • 慣れ親しんでいる言語で行う

コンカレンシー問題

  • Flakyテストだとコンカレンシー問題があると思う
  • Flakyの診断をする。もう一度実行するなどを行う
  • ある程度のレベルのFlakynessはあるがそこまで心配していない
  • パーフェクトな状態ではない

マニュアルテストとの兼ね合いについて

  • マニュアルテストとのリンクにしているのか
  • マニュアルでメンテを行っている
  • 必要でないdependencyは削除しているが、基本的にはマニュアルで行う
  • 過度に依存している問題はあるが許容する必要がある

包括的なテストについて

  • 包括的なテストであるが、どのような形でどのタイプを行うと選択しているのか。
  • ある制約がある
    • どのくらいの規模で…
      • 15分
      • 4Coreで
  • E2EテストはFrameworkの中で行う
  • 大きなインテグレーションテストを行う時、45分の中でテストをしていく。
  • システムテストだけではなく必ずUnit testとシステムテストの両方が必要である

Flag optionについて

  • Flagの組み合わせの問題に直面にしなかったのか。
  • 全ての組み合わせをテストするのは不可能ですよね?
  • Flagの組み合わせに対しては相当きつい制約をしている。
    • 例えば、キャッシングに制約をかけるようにしている。
  • 例外にすることはできるがほとんどしていない。
  • Optが失敗してDebugが成功することもあるが…。

  • 400万のこーどがあると言っていたが…。

  • プロダクションテストはあるが、その他のテストはしない。
  • 新しいVersionとして全てうまくいくか
  • プロダクションサーバイメージに対して行う
  • sandboxテストとプロダクションテストは違うということか?
  • そうです
  • これはABテストか?
  • そういうことです

420万のテストケースについて

  • 420万のテストケースは増えていっているのでしょうか?
  • テストプールは常に増えていっている
  • テストケースの最適化は行っているのか?
  • 自動化の分析は行っていない。
  • ただしテスト品質の解析をしている。
  • 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない
  • Backendが有限になると思うと、テストの質に意識するようになった。
  • テストについても何らかの責任をもたせることは大切

  • UTestで開発者が作ったもの。自動的なケース。自動化で良い点。どこでどこで使われているのか

  • テストを書くことが企業理念になっている
  • テストリソースを消費してしまう
  • 探求にも時間がかかってしまう

感想

  • テストケースをbreakした時の判断の仕方が良いなと感じた。
  • 「Flaky」という言葉を使って、テストの種別をするというやり方は参考になった。

「ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて」パネルディスカッション聴講レポート #ICST2017

はじめに

  • ICST2017の中で、「Quality and testing in Software Engineering curriculum」(ソフトウェアエンジニアリングカリキュラムの中での品質とテストについて)というタイトルで、各国の大学教授・准教授が登壇して、パネルディスカッションを行いました。

  • ちなみに、聴講者も意見を出していたのですが、意見を出していた殆どが、前回の記事で書いたGoogleAppleのエンジニアだったと記憶しています。

nihonbuson.hatenadiary.jp

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation

このパネルディスカッションのコンセプトについて(司会のShlomo Markより)

  • 最近4年間でソフトウェアのエンジニアリングをやっている
  • ここでは、ホワイトペーパーを出している。
  • Test、クオリティについて産学連携には沢山の問題がある。
  • それに関しても、私もできるだけ研究に移したいと思う。
  • それでは、パネリストの方には自己紹介をしてもらいたいと思う。

自己紹介

  • パネリストには、何を課題として考えているのか伝えてもらう。

Ina Schieferdeker

  • 品質エンジニアリング、解析についてもどういう教育が大学で行われていくのか考える必要がある。

Jens Krinke

  • 当初、ソフトウェアエンジニアリングのプログラミングに関しても、問題解決ベースだった
  • 学生は最初からアプリケーションを作っていた。
  • 学生はハッキングなども技術をやったりもしている。
  • しかし本当の意味を理解していない。
  • 普通のところからソフトウェア・エンジニアリングを話すことになる。
  • テストもそうです。
  • 5年間を考えてみると、業界が変化していくので追いつかなければならない。
  • コンセプトを考えて、テストの要素をなぞらえていかなければならない

Tanja Vos

  • プログラミングをしているのに対し、テストコードを書かなければならない。
  • それは難しい。
  • テストに関しては教えを請いたくないと言われる。
  • 教えるときには、何がステートメントなどを教えて、テストの方をやらなければならない。
  • しかしテストを後から教えることになっても意味がない

森崎修司

  • 私はソフトウェア工学を教えている。
  • 大学と大学院の両方で教えている。
  • 論文のリクエストやコメントもやっている。
  • その他、博士号過程などで教えている。
  • このディスカッションを行っている中で色々と産業界に提起したい。

討論

Shlomo Mark

  • 各国でどのようなことを行っているか。
  • 例えば私の場合、学生はマシーンランニングがやりたいと言ってきたりする。
  • そのときには最初から品質やテストを教える。
    • 問題に直面するから。
  • そしてUnitテストに入っていく

Ina Schieferdeker

  • 動機づけは、ソフトウェアの作っていることの安全を考えなければならないから。
    • 最近の研究ではエアバッグについて。
    • 他にも医療機器とか。
  • そういったところから見ると、テクニックだけではなく、例えば専門家になったときの責任も教えている。

Shlomo Mark

  • 学生になぜテストを教えるのかが難しい

Ina Schieferdeker

  • 皆さんの仰るところは私も思う。
  • 私は何にそれを適用するのかを教える
  • 研究側ではプロトタイプを使う。
  • ソフトウェアの重要性がある。
  • システム側の品質も必要になる
  • 20年関わっているが、「なぜこれをやらなくてはいけないのか」と学生に問う。
  • どの部分をやっているのかを明らかにさせる。
  • 本当の意味での品質レベルを製品に落とし込まないといけない。

聴講者

  • シリコンバレーの場合、どのような理由でできないかをはっきりさせる。
  • テストに関してバックグラウンドがある人しか雇わなければ良い
  • なので学士以上のところが必要

Jens Krinke

  • このような比較ですが、例えばマシーンラーニングだけしたいと言ってくる学生がいる。
  • そういう学生に対してはソフトウェアテストや品質は学ぶ必要がない。
  • ただし、エンジニアではない人がやるとなると一貫性が無くなる。コンセプトがなくなってしまう。
  • パッケージに関しても、最初に品質を学ばなければならない。

Tanja Vos

  • 教育の最初にクオリティを学ばせないといけない
  • 例えば、
    • プログラムを見ていく。
    • 学生に関してはプログラムで検証していく。
    • デバッグをしていくときに対してUnitテストをさせたりして埋め込む必要がある

聴講者

  • テスト志向というのは非常に大切。
  • どれぐらい文化を変えるのに、テストを分かっていない人を変えるのがすごい大変です。というか不可能です。
  • テストを学んでいない人にテストの話をすると、その瞬間に水を失った魚みたいな顔になる。
  • 結果的に、そういう人を雇用できなくなる

Ina Schieferdeker

  • それから教授がいかに説得させるか。
  • 論文などをICSTに参加している方に向けて書いていますが、学生の教育のタスクとしても書いている。

聴講者

  • 機械学習をやっていてもコードを書いている以上、それを健康的な状態に保つためにはテストが必要。

聴講者

  • 5年間Masterでコンピュータ・サイエンスをしている。
  • 1年目からテストケースを与えてテストコードを書いている、実際に開発者テストを書いている。
  • よりテストパターンとしてできるものをやっていく。
  • 上手くいっているところもあるが、Functionalテストになると、どういう風にやっているのか分からない。
  • ツールも入れて、そこの部分も学生に紹介しようと思っているが、それは出来ていない。
  • テストの話をすると、コードがテスト無しで正しく動いているかどうかという方向性にいってしまう。
  • 文化として試行錯誤するという考え方にできていない。
  • ダメならば別のコードをやればよいとなってしまう

聴講者

  • テストを書くことのクールさに学生が気付いていない。
  • 大学に入る前にテストを書いているという人がいない。
  • なので、カリキュラムの中でも厳しくする必要がある。
  • 例えば、コンテストをするとか、インタフェースを設けるとか。

聴講者

  • これは学生の問題ではない
  • ツールやチャンスはある。
  • この命題に関しては好きな人もいるはず

Jens Krinke

  • 学生がこれが好きではないという話については、学生的にはやることには問題ない。
  • こちら側がカリキュラムを変えている。
  • 多分、1,2年あたりで起こると思うが、4年生の方のカリキュラムを変えている。
  • 同じモジュールを異なったコードにしたり。
  • ソフトウェアエンジニアリングをどのように改善していくのかも大学でやっている

聴講者

  • 学生への教え方が変わっていっていくことに驚いている。
  • 一緒にやっていこうというアイディアですね。

聴講者

  • 最も賢い1年生に対して「テストをやっていないとパスできないよ」と伝えてほしい。
    • それがたとえ宝石のようなプロジェクトをやろうとしていても。
  • テストを書かない人は無理です。そのような人はGoogleのインタビューでは受け入れません。
  • 我々はテストを扱える人を求めている。
  • マーケットも求めているし、アカデミックもそうでしょうか?

森崎修司

  • 優先順位について。何がいちばん大切なのか。
  • 同意です。
  • グループワークをやっていて、何人かの学生はそれを学んでシェアする必要があると思っているようです。
  • プログラミングの講義をやっていると、何人かの人は本人で学んでいく人もいる。
  • テストは教えられるべきものなのか。
  • QA活動は気付いたり、生徒自体が発見していくことが大切ではないのか?

聴講者

  • quality testingについてはどう考えているか?

Ina Schieferdeker

  • 大抵は比較をしている。
  • テスターが沢山いるので、大学で学んでいる人もいるので、ソフトウェアエンジニアリングが厳格に勤勉に学んでいかなければならないものである。
  • ソフトウェアエンジニアリングは完璧なものではない。
  • 他のものも鑑みた上で、何をプログラム化すべきなのか。
  • ソフトウェアエンジニアリング以外のものも含めて、より厳密に扱っていく。
  • 例えば、パブリックセクターとプライベートセクターの両方で構築すべきだと思う。

Jens Krinke

  • いや、そうは思わない。
  • クオリティは他の人がやってくれるからと言われてしまう。
  • これは何年も前のやり方で上手くいかない
  • ソフトウェアエンジニアリングの経験を積んだ人が扱う。
  • 大学では品質を教えることができないのだと思う。
  • セルフエンジニアリングのトレーニングはできると思うが、大規模なことをやっていないので品質のトレーニングは無理です。

Tanja Vos

  • 別の講義で教えるということはダメだと思う。
  • 最初からテストについて教えるべき

聴講者

  • 私は少しだけ同意する。
  • そもそも教育時間が短い。
  • きちんとしたエンジニアを育てる、ある程度の教育、プリ教育として、クオリティエンジニアに関しては1つ1つ教えるだけでなく、他のことも教えることになる。
  • 他の専門性も含めて学ばなせなければならない。
  • 博士号でその道のスペシャリストを育成できればと考えている

聴講者

  • どなたか共創の話があった。
  • ベストスキルというようなコミュニケーションが必要だと思う。

聴講者

  • 私は2つのトラックに分ける必要ではないと思う。
  • エンジニアである場合、もちろんソフトを書いてテストを書かねければならない。

Shlomo Mark

  • テストを教えるとして品質は教える必要があるのか。

聴講者

  • 産業界では別にしている。
  • ただ、別々にしていると上手くいかない。
  • テストも書くのが仕事ですよと。責任を持ちなさいと言っている。

聴講者

聴講者

  • 同じ人がやっている。
  • どういうレベルであっても、自分で作ったのならば自分でテストをしなさいと。
  • なので、システムテストレベルについてはツールを提供したりしている。

Ina Schieferdeker

聴講者

Jens Krinke

Ina Schieferdeker

  • そんなことはないです。
  • テストマネージャはプロダクトマネージャよりも給料が高いです。責任が重いからです。ただし、学生は実感できませんが。

聴講者

  • 学術界の把握ができて嬉しく思った。
  • ただ、その中で大学を通じて色々な課題がありますが。
  • 大学の中で教授で産業界の経歴がある人は?何%ぐらいがそうなのでしょう?
  • 会場を見る限り半分くらいでしょうか。
  • 私は学生だが、このようなコンセプトについてそのようなクラスを受けたいと思うが、実例を学びたちと思ったとき、ソフトウェアのトピックが無くては学べないと思うが。

聴講者

  • ITに10年いますが、テスト駆動形のプロセスです。
  • このようなことを扱えて、学んだことが扱えてよかった。
  • テストでも色々な階層があるが、フォーカスしているのはどのようなテストタイプですか?ストレステストなどがあるが。

聴講者

  • Microsoftの場合はそれぞれ分かれている。
  • プロセスに関しても。
  • Microsoftの場合、お互いに役割がある。
  • ただ、Murat Ozturkさんに同意するわけでない。
  • 違いがあります。
  • Writerがいて、スケールがあります。
  • 少し大きい場合はテストオートメータの友人を入れる。
  • マシーンラーニングとかもそう。

Shlomo Mark

  • 時間が来てしまいました。最後にどうぞ。

聴講者

  • どのようにテストプロセスを作っているかについては、どちらの方法でも良い。
  • 開発プロセスに注入していくか、うまくいっているのか、カバレッジはきちんとしているか。
  • どこかに穴があってはまずい
  • トータルカバレッジを考える
  • プロセスの問題というよりもアプローチの問題。
  • 私のチームもそう
  • インフラでも楽しむことが重要。
  • 使っているコードはテストを作るときにも使っている。
  • テストの世界でも分かるようにする。

Shlomo Mark

  • 何を教えれば良いのかはペーパーも出てきています。

感想

  • 「テストを大学で学ばせる」ということ自体、日本の大学ではなかなか出来ていないことなので、世界とのギャップを感じた。
  • とはいえ、世界的にも教育について悩んでいるのかなとも感じた。
  • さらに「プログラミング」「テスト」を講義として分ける、テストの講義を後から実施すること自体も否定的な意見が多かったのが印象的でした。

「ソフトウェア業界が直面している最先端のテスト課題」パネルディスカッション聴講レポート #ICST2017

はじめに

  • ICST2017の中で、「Bleeding-Edge Testing Challenges that the Software Industry Faces」(ソフトウェア業界が直面している最先端のテスト課題)というタイトルで、GoogleAppleのエンジニアが登壇して、パネルディスカッションを行いました。

  • ICST2017公式ページ

ICST 2017 | 10th IEEE International Conference on Software Testing, Verification and Validation


セッションのコンセプト(司会のAtif Memonより)

  • 今回のようなセッションに近いこととして「産業界とどのようにやっていくか」という題材をほぼ毎年やっています。
  • 前提として学術界では制約のかかるところからやっていく手法をとってます。
  • しかし毎年「産業界には何も起こらない」という結論になっています。
  • なので今年は少しアプローチを変え、産業界の方々にご登壇して頂き、セッション中に出てくる問題に対して学術界から何かを提供できればと考えております。

登壇者の紹介(司会のAtif Memonより)

  • 話しやすい人を選んでいるつもりです。一人ひとりご紹介します。

John Micco

  • 1日目の基調講演を担当しました
  • GoogleのTACチームにいる
  • テストチームとして自動化を行い、開発者にFeedbackをしている
  • ただし、リサーチもしているし、ペーパーも出している

Murat Ozturk

  • Googleでリサーチをしている
  • パブリッシュもしている。

Adithya Nagarajan

  • Appleに勤めている。
  • リサーチャーの悩んでいることも理解しているはずです。
  • Microsoftなどに転職し、現職はAppleです。
  • Appleのオープン化も進めている。

Bao Nguyen

  • Googleに勤めている。
  • モデルベースをやっている
  • リサーチの結果を使い、業務に活かしている

自己紹介

司会

  • 皆さんはリサーチをサポートしている方々です。
  • まずは5分ずつ話してもらう
  • 特に未解決の部分を話してもらう
  • 登壇者にはこのイベントのFeedbackもくださいと言っている
  • 「ここはリサーチを見ているし聞いている」とか「この部分は産業に関しては必要ない」とか言ってもらいたい。
  • 批判をしていただいても結構です。

Adithya Nagarajan

  • 私の勤めているApple知名度…については聞くまでもないですか。
  • ICSTのような学会イベントには2002年に最後に参加して、そこでは色々なことを学んだ。
  • 15年ぐらいこの業界にいるが、産業界と学術界での色々なGAPを見ていた。
  • 我々は、実は原始的な技術を使ってハイクオリティなサービスを作っている。
    • Fuzzyなツールを使っている。
    • ツールはもっと拡張できるはずだと思っている。
  • 実際にソフトウェア・エンジニアリングを使っている
  • 並列化してアジリティがなければならないと感じている。
  • テスト優位性については変わっていない
  • コラボもできるかもしれないいくつかのエリアがある。
    • データは沢山あります。
      • 仕様データとか。
  • それを使ってテストを改善できるのではないかと思っている。
  • テストスケーリングの問題がある。
    • 優先順位をつけるとか。
  • テストの軽減をしたいと考えている。

Murat Ozturk

  • Adithyaの話を聞いていて、相当似た部分があると感じた
  • Googleに6年以上勤続している
  • ほとんどをテストに関することに費やした
  • マネージャも勉強した。
    • 役割を勉強したいと思った。
    • ロールのカバレッジをしたい
  • ツールとインフラストラクチャもやっている
  • 共通の間違いとして、私たちはテストを書く人だと勘違いされています。
    • 私は最適化をしようとしている。
    • テストケースの効率化などは考えていますが。
  • 問題から始まって、スコープ化して解決しようとしている。
  • Flakyなことをして問題解決をしている
  • 私はあまり良い生徒じゃなかったので、プレゼンテーションの準備が出来ていません。
  • Flakinessは私達のやってきていたことです。
  • どうやったらプロセスの中で緩和できるのか。
  • インフラの中で解決できるのか、これをFlakyテストといっています。
  • どうやって解決するのか。ツールを作って問題を解決したりとか
  • スケールの問題もあります。拡張も重要です。
  • Googleから見た問題に関してお話します。
  • スケールについてはシステムテストレベルだったりテストセットがあります。
  • もっともっと拡張していくと思う。
  • これをうまく最適化できないか考えています。
  • 想像できないぐらい大きいです。
  • ベストなテストケースをなるべく少ない数でできないか考えている。
  • また、その方法を見ていく
  • レイヤーを組み合わせることになると、どのテストをしなければいけないかを見なければいけない。
  • 世の中に非常に多くのアプリケーションが出ている
  • 自動運転車も出ている。
  • この中でももっと調査研究が必要。
  • どういう貢献ができるか、コラボレーションができるか考えている。
  • 皆様に情報を発信し、皆様から情報を得たい。
  • データをどんどん活用してください。
  • 私の方で問題があるので、「誰に聞けば良いですか?」と聞いてくれれば、私が適切な社員を紹介します。

John Micco

  • 解析、仮説については使わなければいけない
  • 問題点は私達が見つけるのとまた違うはず。
  • データセットを見つけてもらえればと思う。
  • 研究もある。
  • もっと大きな産業界のデータセット
  • ただ、問題が少しあります。
  • もっともっとデータを共有するためにオープンにならなければならない。
  • それぞれ独立してリサーチ結果を出している。
  • 同じようなことを同じような問題を抱えていながら別々に発表している。
  • これらを別々にやってはいけないと考えている。
  • 重複してはいけない。
  • 皆さんは接着剤、橋渡しとなるような存在にしてほしい。
  • 機密にするのは意味が分からない。
  • 機密情報でお金を儲けるのではなく、他のところで儲けるべきだ。
  • 全てのデータセットをシェアすべきだと思っている。
  • マニュアルQAはやっていない
  • 2週間1回やっているということを言われたが、本当に必要があればやるべきだと考えている。
  • また他のテクニックについて、Fazzing、自動テストについて。問題はある。
  • 大きなアルゴリズムでバグがあるものはテストしない。
  • リサーチとは違い、適用可能なものからやっていく。
  • 私達ができるものもあった。適さないものもあった。
  • 毎日何百回も起こるので、Flakyの原因を自動的に追求できれば価値があると思う。
  • 似たような問題が他にもあるのだなと驚いた。
  • 現在は99%以上のファームで行われているテストで合格するということです。どれが失敗するか分かる。これはできると思う。
  • 99%を除いた所だけやれば効率良くテストが出来る
  • 回帰テスト・組み合わせテストがある。
  • 例えば、qualityを保証するためにいくつぐらいやれば良いのか
  • 回帰テストを最適化するという話をした。スケジューラの話もした。
  • このようにテストのスケジュールをするにはコンビネーションを考えることが必要です。

Bao Nguyen

  • 私は産業界に移った経歴がある。
  • Scale、スピード、2週間でテストを行う。すぐにテストを行うことがある
  • 同時並行で行うとなると、並行して全部行うことになる。
  • 多ければ良いとなっている。
  • 課題はコミュニケーションの問題がある。
  • Johnさんと同じ。同じ課題に違う方法でやってしまっている。
  • テストもそう。ただし違う意味合いでやっている
  • Googleは仕様を見ていく。
  • 会社によって意味合いが違っていきます。

討論

聴講者

  • スウェーデンの場合、産業界と学会は非常に多くのコラボがある。Ericssonもそう。
  • データがあっても、そのまま使えるわけではない。
  • 例えば関連性が低いものもある
  • このデータは間違っていないのかという確認が必要になっている

Murat Ozturk

  • 確かにそうだと思う
  • 生データはノイズが多くなってしまっている。
  • 研究者のドアを開くという意味で提供したいと思っている。

John Micco

  • 色々なことがデータに入っている。
  • データに有用であるという約束はできませんが、データをサニタイズするだけでも意味がある。
  • とはいえ、リサーチャーによって価値のある物になっていないといけない。

Murat Ozturk

  • 一つ気付いたことがあった。
  • 私はもっと学会に出るべきだと思った。
  • 足がかりはそこからできるのではと感じている

聴講者

  • フライトリサーチをやっている
  • 日常のビジネスと並行することが難しいと感じている。
  • 何かアイディアはありますか?

Adithya Nagarajan

  • モデルベースのテスティングのリサーチャー、学生だった頃、業界はモデルベーステストを使っていなかった。
  • 今やっていることをスケール化していくことができる
  • 業界側ももっと学ぶ必要がある。
  • だんだん起こってくると思う

聴講者

  • リサーチの結果は出ているが、インプリが出来ていない。
  • アイディアはあるが、やり取りをするには時間がかかる。

Murat Ozturk

  • その見方から欠落しているものがある。
  • どう応用し、適用するのか。
  • もしリソースが食うのであれば、インフラも見ていく必要がある。

聴講者

  • リサーチだけでなく業界側も両方必要。
  • How toの部分のチャンス、メソッドをまだ把握できていない。

聴講者

  • 協業していくためにはリサーチのペーパーをソリューションとしてシンプルではないかもしれないが、概念的なものがあれば良い。
    • シンプルなもので適用できるもの
    • 複雑だが適用にローコストなもの。
  • 概念的に素晴らしくても適用が難しいことがある

Bao Nguyen

  • 一つ思うのは、理解し合えていない。
  • ソリューションがシンプルでも進化させていかないと分からない。

Murat Ozturk

  • そのとおりだと思う。
  • 現在だと理論を理解するのにエネルギーを使って、使えるのか考えるのに時間を食う。
  • このソリューションの応用がペーパーでわかると良い

聴講者

  • ソフトウェアエンジニアリングのリーダーをつとめていて、品質などを扱っている。
  • エンジニアは問題を解決するためにできている。
  • 大学、学会と業界にGAPがあるとおっしゃっているが、ソフトウェア・エンジニアリングが科学を用いて解決することをしているはず。
  • デンマークではYahooのクラウドプラットフォームがある。
  • 課題を投げかけてくれれば、これが解決できるかどうかの判断ができるはずだ。

Murat Ozturk

  • 私もそう思う

聴講者

  • 先程の方が仰ったような、シンプルソリューションの話。
  • 通信会社と一緒にやっている。
  • もっともシンプルなものが80%ぐらいしかできない。
  • 洗練することを繰り返すことで皆さんが使えるものになる
  • シンプルソリューションを示すのは産業界としては必要なのかも。
  • もしも必要ならば、こういう可能性があるなという示す

Murat Ozturk

  • そのとおりだと思う。
  • 非常に驚いたが、10年ぐらい学術界に出てなかったが、Industryトラックがあることに驚いた
  • Topicも非常に面白かった。
  • 中間を考えていかなければいけないと感じた。

Bao Nguyen

  • ここで勘違いしてもらいたくないのは、シンプル化はモデルではなくシンボル的なものです。
  • モデルが非常に難しくても、お互いが努力することでもっとわかりやすく出来る。

Murat Ozturk

  • 企業はスケールができる。
  • それがわかった上で、私達が持っているリソースを提供できればと思う。

聴講者

  • おそらく課題を全部が解決したら中小企業になると思う

感想

  • GoogleAppleでも同じようにテストの効率化について悩んでいると知ることができて良かった。
    • ただし、テストケースそのものに興味を持っている点は、テスト設計に興味を持ち、その部分から効率化しようとしている日本のテスト業界とアプローチが異なると感じた。
  • 研究のシンボル化という話はうなずける気がする。
    • 企業の研究についても、結局どうやって他社に適用してもらうかが重要だと思ってる。
  • パネルディスカッションの進め方として、登壇者だけでなく聴講者も参加している形式は良いなと感じた。

テストの教育についてのパネルディスカッションはこちら

nihonbuson.hatenadiary.jp

  • この記事のパネルディスカッションの直後に行われたものです。

「GitLab Meetup Tokyo #1」に参加してきました! #gitlabjp

3月2日、GitLab Meetup Tokyo #1に参加してきました。

gitlab-jp.connpass.com

全体的な感想

  • GitLab CIが当たり前のように出てくるなー

  • GitLab.com事件があったからか、バックアップがHOTな話題だなー

  • 結構改善されてるんだなー

という感じ。

各発表内容の紹介

当日中に記事を書いたので、そのリンクを貼っておきます。

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

nihonbuson.hatenadiary.jp

  • GitLabがどれだけ活発なコミュニティなのかということがすごい理解できました!

GitLabの実践的な運用

nihonbuson.hatenadiary.jp

  • 生半可な気持ちでMySQLにしない方が良いということが分かりました。
  • バックアップ大切!

GitLabコミュニティへのコントリビュート

nihonbuson.hatenadiary.jp

  • GitLabに限らず、コミュニティへの貢献方法が学べました!

ここがすごいよGitLab CI

nihonbuson.hatenadiary.jp

  • Twitter上と変わらぬ @sue445 さん節炸裂の発表でした。
  • yamlでスッキリ書けるのって本当に良い!
    • 私もその虜になった一人

GitLab LT

nihonbuson.hatenadiary.jp

  • 4名の方々のLTがありました
  • チームでの運用・大規模な場合の運用など、様々な立場の人の発表でバラエティに富んでいました!

第2回開催決定

  • 第1回の開催中に第2回の募集が開始されました!

gitlab-jp.connpass.com

  • もう一般参加枠は埋まってしまったみたいなので、是非、発表者とかスポンサーでの参加を!

「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」をなくしたい