syobochim-doc

本ドキュメントの目的

開発担当者が開発環境について理解するためのドキュメントです。 本ドキュメントを参照することで、開発者は開発環境の全体構成を知り、スムーズに開発作業を開始することが出来ます。

想定読者

以下読者を想定しています。

  • PG / UT工程中の開発担当者

前提知識

以下知識を保持していることを前提とします。

  • PG / UT工程中に必要となるプロセスに関する基本的な知識。
    • テストコードの作成やソースコードレビューについて知っている
  • 構成管理についての、基本的な知識。
    • Subversionを使用した開発経験を保持していればOK

書いていること

  • ソースコードの構成管理の全体像
  • Gitを使用した構成管理についての基本的な考え方（リモートリポジトリとローカルリポジトリ、ブランチ）
  • 開発をスタートするうえでの最低限の操作

書いていないこと

  • そもそも構成管理とはなにか
  • ツールのインストール方法、初期設定方法(環境構築ガイドに書いてあるようなこと)
  • 実行コマンド
  • 各種ツールの高度な使い方

ソースコード管理の流れ

PG・UT中のソースコード管理の流れを以下に記載します。

_images/all.png

開発概要

使用ツール
  • バージョン管理：Git / GitBucket
  • ビルドツール：maven
  • ライブラリ管理：Artifactory
  • CI：Jenkins
  • ソースコードの品質監視：SonarQube
各ツールの説明
  • GitBucket：Gitのリポジトリサーバ。ソースコード管理、ソースコードレビュー、ソースコードのマージに利用。
  • Artifactory：リポジトリ管理システム。PJ用のmavenリポジトリとして利用。基盤ライブラリなどを管理する。
  • Jenkins：CIサーバ。継続的にテストや静的解析を実施し、品質を確保する。また、リリース用の成果物の作成や、リポジトリ管理システムへのライブラリの公開なども行う。
  • SonarQube：ソースコード品質管理システム。ソースコードに対する静的解析や、ユニットテストのカバレッジなどからソースコードの品質をメトリクスによって可視化する。
開発フロー
  1. 開発者は最新のソースコードをGitBucketから取得する。
  2. mavenを使用して、プロジェクトが依存するライブラリをArtifactoryから取得し、依存関係を解決する。
  3. プログラムを修正し、gitにてバージョン管理(commit)する。
  4. 修正したプログラムをGitBucketにpushする。
  5. JenkinsはGitBucketから最新のソースコードを取得し、アプリケーションが常に動作する状態か監視する。
  6. JenkinsとSonarQubeは連携されており、ソースコードの品質を常に監視する。
  7. Jenkinsは、各リポジトリのソースをライブラリ(jar)としてArtifactoryに格納する。

Gitについて

Gitの使用方法を以下ドキュメントに記載します。
コミットコメントやレビュー方法についても記載しているので、目を通してください。

Git利用ガイド

記載内容

書いていること
  • Gitを使用した構成管理についての基本的な考え方（リモートリポジトリとローカルリポジトリ、ブランチ）
  • 開発をすすめていくなかでの最低限の操作方法
  • GitとSubversionの構成管理の考え方の違い(説明のなかで少し出てきます)
書いていないこと
  • そもそも構成管理とはなにか
  • ツールのインストール方法、初期設定方法(環境構築ガイドに書いてあるようなこと)
  • 実行コマンド
  • 高度な使い方

使うツール

開発PC

開発PCには次のツールがインストールされていることを前提とします。

  • git
  • SourceTree
リモートリポジトリ
  • gitBucket(ブラウザから参照出来る画面です。)

SubversionとGit

構成管理の考え方についてはSubversionとGitでの大きな差はありません。
どちらも、開発者はローカルにてソースコードの変更し、リモートリポジトリにソースコードを格納することでソースコードの共有を行います。
また、ソースコードの変更差分のバージョン管理はリモートリポジトリにて行います。

SubversionとGitでの開発者の操作のながれを２つの図で記載します。
以下の2つの図を見比べてみても、開発者の操作はほぼかわりません。
ただし、 Gitにはローカルリポジトリというものがある ということを覚えてください。

注釈

※SubversionにはあってGitにない操作、GitにあってSubversionにない操作を黄色枠で囲っています。

Subversionの操作のながれ
_images/Subversion.png
Gitの操作のながれ
_images/Git.png
ローカルリポジトリとリモートリポジトリ
ローカルリポジトリとは、開発PC内で（オフラインで）コミットの記録を保管しておける領域です。ローカルリポジトリへのソースコード変更の登録は”自分だけ“がわかります。

リモートリポジトリはgitBucketにて管理しているリポジトリのことです。リモートリポジトリへのソースコード管理の登録は”チームメンバへ“変更内容を展開することが出来ます。

Gitでは、ローカルリポジトリに一度変更差分を登録し、その変更差分をリモートリポジトリに反映していきます。

操作が”ローカルリポジトリに対して“か”リモートリポジトリに対して“かを意識しましょう。
以下解説では、上図のようにローカルリポジトリ(青色の四角)・リモートリポジトリ(オレンジ色の雲)を分けて解説していきます。

ブランチについて

(Subversionでは開発のために各開発者がブランチをきることはほとんどなかったと思いますが、) Gitでは各開発者がブランチをきって開発をすすめていきます。
Gitでは強力なマージ機能があります。そのため、ブランチをきっても、マージする際のコストはあまりかかりません。
ブランチを切って開発を進めていくことで、以下のような利点を得ることが出来ます。

  • PullRequest機能（後述します）を使用することで、ブランチ間のファイル差分を容易に確認することができ、レビュー対象が明確にわかります。
  • ブランチを切り替えてレビュー対象のソースコードを容易に動作確認することが出来ます。
  • ブランチを切ってレビュー完了後にマージすることで、ソースコードを必ずレビューする運用にすることができ、ソースコードの品質を維持することが出来ます。
ブランチの種類
PGUT工程中は、主に以下のような種類のブランチができます。

  • masterブランチ
    • チームにて管理するブランチ
    • 本番環境へリリースするソースコードを管理する
    • モジュール：ブランチ＝1：1
  • developブランチ
    • チームにて管理するブランチ
    • 開発中のソースコードを管理する
    • 既にレビューに合格しているもののみ格納する
    • モジュール：ブランチ＝1：開発拠点数(※開発拠点が一箇所であれば1)
  • featureブランチ + 開発者が作成し、開発者が削除するブランチ + 開発中かつレビュー合格前のソースコードを格納する + モジュール：ブランチ＝1：他
ブランチの概念
以下の記載方法では、ブランチの時系列を表すことが出来ます。
ただし、本ドキュメントでは、「ある時点でのリポジトリの状態を断面化したもの」としてブランチを説明していきます。
_images/gitFlow.png

ブランチを切り替えることで、ローカルファイルがブランチごとに変更されていきます。
今自分がどのブランチにいるのかを意識しましょう。
なお、上記 Gitの操作のながれ のイメージ図に記載しましたが、各開発者はまず開発PCのローカルリポジトリのファイルに対して変更を登録していきます。

_images/git-branch.png

実際の操作

では、実際の操作方法について記載していきます。
状況にあわせて以下リンクを参照してください。

対象読者
以下全てに当てはまる人を対象読者としています。
ただし、操作方法リンクに★をつけて補足を記載している箇所は、全員が参照するようにしてください。
  • Subversionを利用した開発経験がある。
  • Gitを使うのは初めて。
  • SourceTreeをインストールしている。

結合テスト工程のリリースについて

記載内容

結合テスト環境でのリリースの流れと手順です。

既存のリリース手順はなく、リリースに対しての品質を担保できれば問題ない、という環境に対してのリリース方法を記載しています。

前提

結合テスト時の全体構成
今回、メンバーは2拠点にて開発・テストを実施する。
ただし、ソースコードの修正は開発用サーバ上にて管理し、各環境に対してはリリースおよび打鍵テストのみ行う。
それによって、拠点間・環境間で、ソースコードの整合性がとれない問題は発生しない。
_images/itKose.png
各ツールの説明
★gitBucket

ソースコードのバージョン管理を行っているツール。
前回リリースしたソースコードと今回リリースするソースコードの差分を確認することが出来る。

★Jenkins

継続的インテグレーションツール。
バージョン管理されたソースコードの最新断面を取得して、コンパイル・テストを実行する。
コンパイルエラーが発生しないこと・自動テストが失敗しないことを確認することが出来る。
また、Jenkinsから各リリースバージョンのjarファイル/warファイル/earファイルを作成することが出来る。
jarファイル/warファイルは自動的にArtifactry（後述）に配置され、バージョン管理される。

★Artifactory

ライブラリを管理するツール。
リリースするjarファイル/warファイルを管理する。
開発者は各モジュールのファイルをダウンロードして、開発環境へのライブラリ管理の依存関係として使用することが出来る。
ライブラリアンはリリースする資源としてArtifactory上のjarファイル/warファイルをダウンロードすることが出来る。
また、結合テスト環境にリリースするearファイルもArtifactoryからwarをダウンロードして作成する。

ブランチ

ソースコードを管理するgitブランチは以下のように運用する。なお、各ブランチの役割は以下の通り。

  • masterブランチ ... 本番リリース用のブランチ。基本的には本ブランチはIT工程にて使用しない。
  • mainブランチ ... 結合テスト環境リリース用のブランチ。本ブランチにて開発者が結合テスト環境へリリースするための最終確認を行い、結合テスト環境へ資源をリリースする。
  • developブランチ ... 開発用ブランチ。本ブランチにてリリース前開発者がUTレベルの打鍵テストを行う。なお、レビュー済みのソースコードのみ格納されているブランチである。
  • fixブランチ ... 不具合・仕様変更対応を行うブランチ。対応完了後はdevelopブランチへマージされる。
_images/branch1.png
本ドキュメントに出てくる役割
  • 開発者 ... 実際にソースコードを修正する人
  • リーダー ... 各開発者が作成したソースコードに対して品質を担保する役割をもつ人
  • ライブラリアン ... 構成管理およびリリース作業を実施する人

おねがい

本ドキュメントを読んで気づいたことやフィードバックなどあれば、次のURLからissue登録いただきたいです。

issue登録先

このエントリーをはてなブックマークに追加