リリース用モジュールのチェックツールを作ってみた - Qiita
背景 Webシステムをリリースする際、私が携わっているプロジェクトでは以下の操作を行っています。 Gitでdevelopブランチの内容を、releaseブランチにマージ releaseブランチにチェックアウト リリース用の設定がなされていることを確認。 warファイルを作成 リリース用の設定がなされていることの確認項目は、10~20個です。たとえば、以下のような項目です。 DB接続先 FTPやDBなどのパスワード（テスト環境と本番環境はパスワードを変えている。間違って本番環境にアクセスしないようにするため） 画面に「テスト環境」という文字が表示されていない リリースの頻度は3ヶ月に1回なので、確認自体はそこまで負担ではありません。 目視確認では漏れる恐れもあるため、勉強も兼ねてツールを作ってみました。 まあ、ツールが間違っているという可能性もありますが。。。 ツールの中身 構成 JUnit
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
