「チーム開発実践入門」を読んで学んだことを随時、(自分のためだけに)纏めていきます。書籍だけから得た知識で頭でっかちなので、今後、CI/CDの実践を交えて情報を追記していければ。※Gitにおいてタグとブランチは別の名前空間に属しているが、通常利用においてはそれを意識しなくてよいようになっている。同一名になる場合は、「refs/tags/v0.1」など明示する必要がある。git-flowでは中央リポジトリにメインブランチを2つ、各開発メンバーのリポジトリにサポートブランチを3つ、決まったモデルを作ることを提案している。P84メインブランチ中央リポジトリとそれをクローンした各開発者リポジトリにずっと存在するメインのブランチmasterリリースするためのブランチ。リリースのたびにタグ付けする。develop開発用ブランチ。リリース前の最新バージョン。サポートブランチ原則、各開発メンバーのリポジトリにだけ存在し、役目が終わったら消える短命なブランチ。featuredevelopから派生し、特定の機能開発のために作成されるブランチ。機能開発が終わったらdevelopにマージされて消える。releasedevelopから派生し、リリースのために準備をするブランチ。リリースのための準備作業中、余計なfeatureが混ざり込まないようにするために作られる。リリースが終わればmasterとdevelopにマージされて消える。hotfix主にリリース済みの製品に障害があったときなどに緊急的に作られるブランチ。masterから直接派生し、バグを直したらmasterにマージされ、タグを打つ。このバグフィクスが将来漏れないように、同時にdevelopにもマージする。そのときリリース作業中でreleaseが存在している場合は、そこにもマージする。新機能やバグ修正を行う際、その都度に内容や目的を記述したチケットを起票する。チケットの内容に応じて適切にコードを修正してコミットする。このとき、コミットログに関連するチケット番号を入れる。チケットにもコミットログの番号を記入する。チケット駆動開発を徹底するバージョン管理システムがもっているクライアントサイドフックやサーバサイドフックを用いるとよい。コミットメッセージのなかにチケット番号が入っているかどうかチェックし、入っていない場合はコミットを受け付けないようにする。Requestの便利さが知られ普及した今となっては、あえて自分たちでGitリポジトリをセットアップしてTracまたはRedmineをリポジトリブラウザとして使う意味が薄れました。素直にGitHubを使うのがコスト的にも合理的な時代になっています。リポジトリブラウザとしてGitHubを使い、TracやRedmineはチケット管理システムとしてのみ使うのが良いでしょう。HooksにもTracとRedmineは用意されていますので活用してください。Git自身のHookを使う方法GitのHookはクライアント・サーバサイドそれぞれで動作するHookがリポジトリの.git/hooks/の下に多数用意されている。.samplesという名前のサンプルスクリプトを参考に記載すべし。担当者が複数であることも単独であることもある※タスクに落とすときはチケット管理システムでチケットの親子関係を作り、親:ストーリー、子:タスクとすると良い。※組織の境目で表計算ソフトと使い分ける方法もある。組織横断の時点では表計算ソフトで扱い、具体的な組織内のタスクに落ちてきたらチケットを起票、という感じ。○CI(継続的インテグレーション)インテグレーションとは以下のプロセスのことをいうすべてのソースコードを1箇所に集める依存するライブラリなどにパスを通す必要な場合はコンパイルするデータベースの構築とデータのロードを行う必要に応じてミドルウェアの設定や起動を行う単体テストと結合テスト、ユーザ受け入れテストなどを実施するこれらのプロセスを常時実行するのがCI。振る舞い駆動開発(BDD)最初にテストコードを書くのはTDDと同じただし、テストというよりは要求仕様に近い記述をする仕様を書いてからアプリケーションコードを書くスタイルCucumber-jvmを使って、自然言語で振る舞いを記述する例が挙げられていたこの例では、振る舞いを記述してテストを生成→テストクラスにコピペして実行の手順Pythonで同様のものはないのか??behaveというBDDフレームワークが有名な模様(あとで使ってみよう)カバレッジコードカバレッジとは、対象となるアプリケーションコードのうち、テスト時に何%のコードが実行されたかを表す指標。これを計測することによって、対象のコードがどの程度テストされているかを視覚化できる。コードカバレッジは対象となるアプリケーションコードが実行されたかどうかだけを計測するものであって、テストコードの内容がテストとして妥当化どうかは判断できない。この点はコードレビューで担保すればよい。壊れたらその時点で同じリポジトリの同じブランチ上で作業しているすべてのメンバのコミットを禁止する必要がある。基本はSubversionと同じで同一ブランチ上で作業しているメンバのコミットを禁止する。git-flowのように、メンバー各位がリポジトリを持ってプルリクを送る運用の場合はその限りではない。(GithubとTravisCIの組み合わせだけでなく、Github-Jenkinsでもプラグインを使えば実現可能)デプロイの自動化ここではプロビジョニングツールを以下の3つにわけ、具体的なツールでの例を挙げて説明している。BootstrappingサーバOSの設定や仮想マシンによるサーバ立ち上げの自動化に関するツールConfigurationサーバやミドルウェアの設定を自動化するツールOrchestrationソースコードのデプロイやリリースに関わるサーバの操作などを自動化するツール以下、それぞれのレイヤーに属するツールの説明。BootstrappingKickstartベアメタルサーバのOSインストール時に初期設定を記載したConfigファイルを読み込ませて、一律同じ設定のサーバを作成する。Vagrantベアメタルではなく、VirtualBoxの仮想環境の設定を自動化するツール。Kickstartのように各用途、各人にベアメタルサーバを用意できないときはこちらを用いる。プラグインを入れればAWSにも使えるらしい。Rubyで書かれたConfigurationツールのChefとは相性が良い。ConfigurationChefサーバ設定を自動化するツール。Severを構築するとよいらしい。検証-本番等の環境差異については、レシピ中の変数にattributeとして記載できるため、差異を吸収できる。よって、全環境で同一のCookbooksを利用すべき。注意事項としては、本ツールを使う以上、手作業でのサーバ構築を禁止しなければいけない。serverspecサーバ構成をユニットテストするためのツール。Chef等でサーバ構築を行ったあとに利用するとよい。xx)みたいな簡潔な書き方であり、すぐに慣れると思われる。以下、Bootstrappinng→Configurationへのベストプラクティスとして、以下のような例が挙げられています。ベストプラクティス11Vagrantでクリーンなインスタンスを起動2ChefのCookbookとserverspecのテストケースをGitからチェックアウト3Chefが実行され、サーバが設定される4serverspecでサーバの状態テストが実施される5実行結果がJenkinsにフィードバックされるこれら一連の処理がVagrantfileに記載され、実行されます。ベストプラクティス2ベアメタルサーバを使わざるを得ない人向け(自分はレガシーな職場にいるのでこちらのほうが使えそう...)。こちらは上記のVagrantがKickstartに変わったようなものだと思っていただければよい。※Kickstartは仮想環境のインストールにも適用できるため、ベアメタルに行く前に検証は必須。OrchestrationCapistranoCapistranoサーバを用意するだけど、アプリやDBサーバに手を入れることなく、Pushでリリース作業を行ってくれる。FabricPython製のツール。Capistranoとの違いは、処理の直列/並列を簡単に切り替えられること。ゼロダウンタイムデプロイメントの例を挙げてこのメリットが説明されている。全体のジョブ管理用のJenkinsとFabricの組み合わせの例が挙げられています。Jenkinsでマスター/スレーブノードを構成し、スレーブエージェント経由でFabricを実行しています。この構成を取ることで、Fabricの実行結果をJenkinsのコンソールログとして残すことができます。Fabric等でリモートサーバに接続する際、どこからでもrootログインを許容するとセキュリティを損なうことになる。Fabric等を実行するサーバに限定してrootログインが可能なように設定すること。それらのサーバは限られたユーザのみ限定してログイン可能とし、公開鍵認証方式でセキュリティを担保するとよい。sshdでは、/etc/ssh/sshd_configにおいて、Matchディレクティブという条件分岐を設定でき、条件にあったIPアドレスやユーザアカウントからのSSH接続要求があった場合に指定した設定通りの振る舞いを制御することが可能。例では、Fabric実行サーバからの接続のみrootアカウントへのRSA認証でのSSH接続を許可している。参考)P255では手作業のデプロイで便利なツールが紹介されている。Windows上で動作するターミナルソフトで、開いているすべての接続にキー操作を同時におくることができ、ログイン先のサーバですべて同じ作業を同時に実施することが可能。RLogin同様、複数の接続先へ同時にコマンドを送信できるブロードキャストコマンド機能がある。LinuxやまcなどのUnix環境で使える同時実行ツール。運用について考慮するブルーグリーンデプロイメントロードバランサによりテストアカウントはブルー環境に割り振られ、一般ユーザはグリーン環境に割り振られる。この章はなんとなく言ってることは分かるんだけど、経験が乏しすぎてなんとも...リグレッションテストP289で、Seleniumで取得した画面キャプチャをImageMagickで比較する手法が挙げられている。この手法は試したことがないので、ぜひ試してみたい。レガシーな職場(多くのSIerの現場)でも有効なのではと思う。Okazaki@okapee0608仕事でPGを書く機会はほぼ無いため、個人的にサービス考えたり、プロトタイプ的なものを作ったりしてます。好きな言語はPython、最近はkaggleやatCoder等の競技プログラミングで技術力を高めたいと思ってます。Flutter&Dartでアプリも開発中。インフラ系の話も大好物です。気兼ねなく絡んでいただけると嬉しいです。upLoginユーザーは見つかりませんでした。