「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

acai

English⇒Japanese

jhoo0509

English⇒Japanese

yoko

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

[翻訳]GitLabハンドブック>エンジニアリング

 現在の位置:チームハンドブック 目次>エンジニアリング
 

  連絡方法
 

  • Public Issue Tracker (GitLab CEの場合); 不特定多数に公開しては問題が発生するような一部の題材については、公開する相手をチームメンバーに限定する必要がある。極力は、このツールを利用して、ユーザーと情報を共有するのが望ましい。
  • チャット チャンネル; #development, #vpe, #frontend, #infrastructure, #ci-cd, #support の、どれか当てはまるチャンネルに投稿することが求められる。細かい質問など、イシュートラッカーにとっては無駄となる情報であったり、emailを送信すると相手の負担になりそうな情報は、こちらに記述すること。
  • VPE Office Hours: Eric Johnsonが、毎週Zoom会議システムで開催しているオープンオフィスアワー。質問や、フィードバック、ハンドブックの変更について問い合わせることができる。通例 太平洋沿岸標準時の木曜日 午前9時から、1時間に渡って開かれる。都合により変更がかかることがあるので、正しい時刻は彼のカレンダーで確認せよ。

 

  その他関連ページ

 

  GitLab レポジトリ

  GitLab は大量のサブグループで構成されている。それらのサブグループが入ったレポジトリが、GitLab のレポジトリ(群)といえるだろう。それらのリストがGitLab Engineering Projects pageに掲載されているので、ぜひご確認いただきたい。
 

  レポジトリを追加する時の手順:

  1. 追加するプロジェクトは、アプリケーションとして利用されるものなら、必ず名前空間「gitlab-org」の下に入れること。その他わが社の活動に関わるものについては、名前空間「gitlab-com」に入れること。わが社で必要とされるプロジェクトは、全てこの2つの名前空間のいずれかの配下にある。
  2. プロジェクトをGitLab レポジトリのリストに追加する。
  3. レポジトリにMITライセンスを付与する。これについては、gitlab-ceレポジトリのMIT License 条文をコピー&ペーストするだけで構わない。
  4. レポジトリの「CONTRIBUTING.md」ファイルに、"Developer Certificate of Origin and License"という題名のテキストを設けよ。内容については、gitlab-ceレポジトリのDCO + License section 条文をコピー&ペーストするだけで構わない。
  5. 新しいレポジトリを作る上での細則については、Contribution Guideに記述されている。Contribution Exampleを参照すべし。
  6. プロジェクトの「README.md」に、「CONTRIBUTING.md」へのリンクを設ける。

 

  エンジニアリング チーム

 

 

  新しいエンジニアチームを発足させる

 我々は開発を急いでいる。必要とあらば、すぐさま新しいチームを開設する。新たなチームのカテゴリ分けは、主にBackendチームが決定する。他にもBackendチームには、その班におけるプロダクトマネージャーを任命する役割がある。

  それぞれのチームには、その場に適したスキルの持ち主を配属し、なるべく少数精鋭で行動することが望ましい。

 我々が独立したチームを発足させるには、次の要点のいずれかを満たす必要がある。

 

  • 特定の機能の開発に、最低限でも1年はかかる場合
  • たとえば、
    • 熟練したエンジニアマネージャーとエンジニアが必要な案件
    • 熟練工が多忙につき、新任あるいは中継ぎ(Intermediate)エンジニアマネージャーと常任スタッフエンジニアで、開発を進めなくてはならない場合
  • 中継ぎ(あるいはそれ以上の)エンジニア2名が、継続的に働かなくてはならなくなった案件
  • 常任スタッフに2名の欠員が出てしまった班
 これらの基準のいずれかに当てはまった場合は、技術班の再編成が行われる。チームが開始される前にプロダクトマネージャーから決定する場合は、なるべく他の技術班でプロダクトマネージャーをしている者を充てることが望ましい。

 

  班立ち上げの段階で、イシューやマージリクエストが送られてきたときには、新しい班のラベルと、従来の編成なら担当する予定であった旧班のラベルの両方を張り付けるべきである。業務の引き継ぎが終了するまでは、両方のラベルが存在する体制が続く。新しいチームが正式に編成されたところで、ラベルの編集・選別が許可され、適切なラベルへの変更が開始される。

 

  コラボレーション

  我々は毎月、定期的に新しいバージョンをリリースしています。これを持続するために、できるかぎりのことをしなくてはならない。たとえば、我々の開発チームは正解各国に点在している。これが、異なる時間軸を作り出すため、世界中のどこかで、誰かが常に働き続けてくれる。

 新たな機能の実装に取り組んでいるときにも、最も効率的に動ける時間帯の人物が、お前も含めて、世界のどこかに存在していることになるので、それなりの生産性が確保できる可能性がある。

 

  コードクオリティと安定性の確保

  コードクオリティと安定性の確保は、我々にとって常に大きな課題である。全体的にはDevelopment Guidesに従って、開発班によっては、以下のガイドブックにも準拠するように。

 

 

  デモ

  この工程は、アジャイル型ソフトウェア開発の理念から着想したものだ。デモを用意すると、出来上がったプロジェクトを、様々な人々の視点から精査してもらえるようになる。未発見のバグや、制作過程では気づかなかったユーザへの不親切さなどを探り出せるかもしれない。開発の透明性を高めることで、我々の開発を効率化できれば、より身軽な活動を可能にする手立てにもなる。
 開発者は、最低でも新バージョン公開の1週間前に、プロダクトマネージャーにデモを提出しなければならない。
 提出後に30分程(あるいはそれ以下)の短い会議を設ける。そこで、完成形に近づけるには何が必要か、受け入れ基準を満たしているか、実装方法の詳細について、簡単な議論・質疑応答を実施する。

 

  カナリア・テスト

  GitLabには、通称「カナリア(Canary)」と呼ばれる開発環境がある。ここで、公表前のGitLabのコードベースに、間違えがないかどうかを確認するためにプレデプロイをする。
 カナリア環境には、ウェブ、Gitサーバー(sidekiq、データベース、制作物が入っているファイルストレージ等の、データ共有要素込み)が用意されいている。UXコードを含む、アプリケーションで仕様が想定される殆どの論理コードを試験できる。デプロイ前に現実世界とほぼ同じような環境で、アプリケーションを試せることが特徴だ。
 

   カナリヤ環境の設定などには、cookieの指定が必要だ。gitlab.comにアクセスしている状態で、cookieの属性を「gitlab_canary」と指定する。本番デプロイ前に発生している問題にイシューを送る時などにも、このフラグが使われる。

 カナリヤ cookieを有効にするには、次のjavascriptを仕掛ける。このコードは、statesとの切り替えに使うブックマークとして機能する。

============================================
javascript:void((function(d){document.cookie='gitlab_canary=' + (document.cookie.indexOf('gitlab_canary=true') >= 0 ? 'false' : 'true') + ';domain=.gitlab.com;path=/;expires=' + new Date(Date.now() + 31536000000).toUTCString(); location.reload();})(document));
============================================


  コードレビュー

  詳しくは、Code Review Guidelinesに従う。全てのマージリクエストには、コードレビューが課されなくてはならないため、このガイドについては、全てのメンバーが理解している必要がある。

 

  デプロイに使われるリソース

  わが社で使用するリソースは、以下の基準で選定される。

  • 実用に耐えうることを前提に、経費が極力掛からないもの。
  • 必要とされるマシン数を確保できるもの。
  • 使用されなくなったマシンなどを、当社員の操作で消去が可能なもの。各社員は使い終わったマシンを、自らの手で処分しなくてはならない。
  • 利用しているリソースが、正式に長期間使用されるものとなった場合、マシンを管理する人間が存在しており、直接連絡が可能であること。
  • ユーザー名さえ登録すれば、すぐさま使用を開始できるもの。(例:Jane Doeという名前のユーザーなら、janedoe-machine-for-testing というリソースを所有できる。)


  Google Cloud Platform (GCP)

  当社における主要なプロジェクトは、ほとんどこのGoogle Cloud Platformに保管している。1passwordの共有ヴォルトから、「Google Cloud Platform」という名前のセキュアノートを探し出して、認証の方法や、アクセスの際の決まりごとを確認することだ。

  コンソールから仮想マシンやKubernetesクラスターなどを構築できる。月額制をとっているため、使用していないリソースは、すぐさま削除してもらわないと、経費がかさんでいく。
 リソースは、通常ならば、クォータ制限値以上を扱えないようになっている。もしも足りなくなってしまったら、Infrastructure issue tracker宛てに、イシューを提出する必要がある。
 

  Digital Ocean (DO)

  開発途中のプロジェクトについては、ここに保管している。チームのメンバーならアクセス可能だ。社員ならだれでも、必要なだけマシンの作成、消去などができる。
 

  Amazon Web Services (AWS)

  通常使われない。社員でもAWSアカウントを所持ている者は少数派と言える。AWSリソースへが必要とされるケースに遭遇したら、詳しい経緯・理由などを詳細に明記のうえ、Infrastructure issue tracker宛てに、イシューを提出してくれ。アクセスに必要な手続きなどについては、そこで説明する。

 

  DevOps Slackチャンネル

  DevOpsに関する問い合わせは、production teamが管理している 次のSlackチャンネル2局のどちらかに送信しろ。ごくたまに、誤ってGitLab.comに連絡を送る者がいるが、こちらも認知に困るので、やめてほしい。

  1. #backend: バックエンド関係のイシュー(例:error 500s、high database load[データベースの読み込みが遅すぎる、異常が発生した])
  2. #frontend: フロントエンド関係のイシュー(例:JavaScript エラー、ボタンが動かない) 

 特に、producitonチームから送られてきた質問、リクエストに関しては、優先度が高いので、注視すること。

 

  開発強化期間について

  詳しくはReaction descriptionにて。

 

  リリースマネージャー

  リリースに関わるツールや、情報、タスクなどを責任を持って管理する役割のことを、リリースマネージャーという。最近のリリースで誰がマネージャーを務めたかは、リンク先のページで発表されている。

 

 時差などの関係で、リリースマネージャーは最低でも2人用意されることになる。

  1. アメリカ時間に1名
  2. ヨーロッパ/中東/アフリカ時間(EMEA)あるいは、アジア標準時(APAC)に1名


 そのほかに、リリースマネージャー経験者が、当初のマネージャー(release cnadidates = RCs)が何らかの事情でデプロイできない事態などに備えて、アメリカ時間に1名、EMEA/APAC時間に1名必要である。出動条件は以下の通り。

  •  リリースマネージャーが、何らかの理由でGitLabをリリースすることが困難になったり、助けが必要である場合。
  •  当初のリリースマネージャーが、別の業務(チェリーピッキング作業、他のRCsの用立て、デプロイ作業など)に追われている場合
  •  リリースの予定時刻に、当初のリリースマネージャーが、航空機に(操縦・あるいは乗客として)搭乗していることがわかっている状況。
 
PDF
更新日:2018-05-26 00:10:26 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://about.gitlab.com/handbook/engineering/ Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】GitLab UX ガイド

GitLab Documentation > GitLab development guides >GitLab UX ガイド  現在、UX documentationの内容を、 design.gitlab.com projectに移行しております。この説明書の更新…2018-05-26 14:48:52

【GitLab 公式 を訳してみた】GitLab UX ガイド>デザイン原則

GitLab Documentation > GitLab development guides > GitLab UX ガイド >デザイン原則  これから説明するデザイン原則は、GitLabの使い勝手が均一されるように制定されました。 …2018-05-26 14:47:51

[翻訳]GitLabハンドブック>エンジニアリング

現在の位置: チームハンドブック 目次 >エンジニアリング   連絡方法 Public Issue Tracker (GitLab CEの場合) ; 不特定多数に公開しては問題が発生するような一部の題材に…2018-05-26 00:10:26

[翻訳]GitLabハンドブック>UX部門

現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが社におけるデザインの原論、表現法、…2018-05-26 00:09:10