Hnoss

Hnoss

GitLabのドキュメントが、CC BY-SA 4.0.になったー!やったー!
カレンダー

文書タグ

フノス(訳者)(215) IT(191) 解説記事(147) マニュアル(82) GitLab CI(60) オープンソース(50) GitLab(40) Linux(38) メディア(34) コンテナ(29) ウェブ制作(27) HTML5(19) DTM(19) おすすめ オープンソース・ソフトウェア(18) Libre Music(18) 百科事典(14) プラグイン(14) 文化(12) ミキシング(11) ソフトウェア(11) セキュリティ(11) 録音(11) MIDI(10) 西アジア/中東(10) 料理(9) ジョージア(9) グルジア(9) 東ヨーロッパ(9) シーケンス(8) 芸能(8) 業務効率化(8) 音楽編集(8) コマンド(8) 音楽(7) 経済(7) ハンドブック(7) マスタリング(7) アプリ(6) Raspberry Pi(6) ワークフロー(5) WordPress(5) JACK(5) マイクロサービス(5) Google(5) Windows(4) Android(4) 映像制作(4) GNU(4) 法律(4) 欧州(4) 音楽プレーヤー(4) Ubuntu(4) 北米(4) Java(3) ソーシャルメディア(3) DAW(3) Python(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) 有角神(2) エジプト(2) ALSA(2) OS X(2) ERPシステム(2) 電子ブック(2) トヨタ(2) バト(2) Krita(2) 電子書籍(2) ウィッカ(2) GPL(2) ERP(2) オカルト(2) Twitter(2) ロスレス音源(2) BountySource(2) スマホ(2) 牛(2) 歴史(2) ニュース(2) GNOME3(2) iOS(2) PlayStation(2) 仮想通貨(2) 古代エジプト(2) マーケティング(2) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) 政治(1) イボ人(1) 国際(1) クリエイティブ・コモンズ(1) amazon(1) キリスト教(1) レビ記(1) Synfig(1) 独占(1) アマナイ(1) 広告(1) KXStudio(1) EU(1) イケンガ(1) 国際公文書館会議(1) マイナビ(1) 募金(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) 出エジプト記(1) 観光案内(1) 絵文字(1) サンフランシスコ(1) パキスタン(1) リクルート(1) ハトホル(1) パン(1) 地方(1) Blender(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ツイッター(1) Youtube(1) 中南米(1) モヘンジョ=ダロ(1) CC(1) 声明(1) 悪魔(1) ラジオ(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) ゲーム(1) パシュパティ(1) 1Password(1) アピス(1) 宗教(1) テレビ(1) OpenToonz(1) 電子教材(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) デザイン(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 日記(1) 聖書(1) 任天堂 DS(1) 教育(1) bi-modal IT(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) Papagayo(1) 写真(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) ヤーウェ(1) CD(1) タブレット(1) 学校(1) 日本(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) アップストリーム・パッケージング(1) 画像(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) サウンドフォント(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) ポータブルソフトウェア(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) クヌム(1) 魔女裁判(1) オンデマンド(1) リーナス・トーバルズ(1) バフォメット(1) UNIX(1) 黙示録(1) スタジオジブリ(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional


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

 連絡方法

  • 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の用立て、デプロイ作業など)に追われている場合
  • リリースの予定時刻に、当初のリリースマネージャーが、航空機に(操縦・あるいは乗客として)搭乗していることがわかっている状況。
原文:https://about.gitlab.com/handbook/engineering/
Creative Commons License
この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス外部リンク
新着文書(Hnoss)

GitLab Plugin system
GitLab Documentation > Administrator documentation >GitLab Plugin system GitLab 10.6より導入。  カスタムプラグインを使えば、GitLa...
UX Department
現在の位置: チームハンドブック 目次 >UX部門   UX ガイド  GitLabの見た目は、 UXガイド を基準に構成されている。このガイドが、わが...
Team Handbook
現在の位置:チームハンドブック 目次  このハンドブックは、GitLabという企業が、どのようにサービスを維持運営していくかを記したものだ。ここに...

新着文書

Bristol’s Last Bookshop shares key facts on the remains of publishing
ブリストルの ラスト・ブックショップ (「最後の書店」)はたぶん、真の本好きのための残本店と言っていいだろう。それは、いくつかの出版社の名作...
Second social leader opposed to dam construction murdered in one week
一人の社会指導者は昨日プエルトリコ・バルディビアで虐殺された。これはアンティオキアで一週間以内に連続して起きた二回目の類似の殺人である。5月8...
Avianca strike leaders fired / Justice for Colombia
コロンビア第一の航空会社アビアンカは昨年9月20日から11月9日の長期にわたり行われたストに参加したパイロット14人を解雇した。解雇された一人、ハイ...

新着Wikipedia翻訳

Flutter (software)
Flutter -------- 原作者:Google 開発者:Googleとコミュニティ 最初の公開:アルファ(v0.0.6)/2017年5月;1年前(2017-05)[1] 試験版の公...
E (programming language)
E(プログラミング言語) AmigaE や e(検証言語) 、 GNU E と混同しないこと。 E -------- パラダイム マルチパラダイム:オブジ...
Van Eck phreaking
Van Eck phreaking(ファン・エック・フリーク) Van Eck phreakingは盗聴の一形態であり、その中では特殊な装置が使用され、電子機器を探るため、隠...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-05-22 13:58:18 Hnoss
2 2018-05-22 13:57:35 Hnoss
3 2018-05-17 15:34:03 Hnoss
4 2018-05-17 15:29:56 Hnoss
5 2018-05-17 15:27:05 Hnoss
6 2018-05-17 15:24:26 Hnoss
7 2018-05-17 15:22:04 Hnoss
8 2018-05-17 15:21:17 Hnoss
9 2018-05-17 15:15:04 Hnoss
10 2018-05-17 15:15:03 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →