リリース用モジュールのチェックツールを作ってみた - Qiita
背景 Webシステムをリリースする際、私が携わっているプロジェクトでは以下の操作を行っています。 Gitでdevelopブランチの内容を、releaseブランチにマージ releaseブランチにチェックアウト リリース用の設定がなされていることを確認。 warファイルを作成 リリース用の設定がなされていることの確認項目は、10~20個です。たとえば、以下のような項目です。 DB接続先 FTPやDBなどのパスワード（テスト環境と本番環境はパスワードを変えている。間違って本番環境にアクセスしないようにするため） 画面に「テスト環境」という文字が表示されていない リリースの頻度は3ヶ月に1回なので、確認自体はそこまで負担ではありません。 目視確認では漏れる恐れもあるため、勉強も兼ねてツールを作ってみました。 まあ、ツールが間違っているという可能性もありますが。。。 ツールの中身 構成 JUnit
JJUGナイトセミナー『Git入門』に行ってみた＆解決策考えた #JJUG - ブロッコリーのブログ
JJUGナイトセミナー『Git入門』に行ってみました。 jjug.doorkeeper.jp Gitはじめの一歩 スライド Gitはじめの一歩 from Ayana Yokota www.slideshare.net 感想 イラストが可愛くてすごい分かりやすかったです！ このスライドを見るだけで、色々とGitのコマンドがイメージで理解できます Gitの本に限らず、なぜ指導書は読者全員がうまく行く前提で書かれているのか そういう意味で大変参考になった発表でした #jjug— ブロッコリー (@nihonbuson) 2016, 1月 25 困ったときのコマンドを沢山伝えてくださったので、色んな場面でこのスライドを見直す機会ができると思います 「Gitは歴史」という言葉が印象的でした。 ちなみに発表を聞いた直後の自分 @kotomacontact git commit ツチノコをジャイアンが
ぼくがかんがえたさいきょうのgitとMavenとJenkinsを使った開発 : toda_k
若いプロジェクトを任せていただく機会があり、これ幸いと普段から蓄積していた「こうしたらいいんじゃないか」を実践しています。今の開発手法も試行錯誤のもとに作られた良い物なのですが、まだまだ上は目指せますよね、ということで。 理屈先行に見えたプロセスもいざ導入すると意外と実践的だったり、逆に簡単なことなのに時間がかかって使い物にならなかったりと、やはりやってみないとわからないことは多いものですね。この記事では開始1ヶ月で試した内容とその顛末をご紹介いたします。 動機：なぜこんな複雑なことをするのか 自動化やCIを導入する動機として、よく貴重な開発者の時間を大切にするためと言われます。私も強く共感しますが、節約した時間を何に使いたいかという点には諸説ありそうな気がします。 もちろんいい仕事をするという最終目標はずれないでしょうが、アクションとして勉強するのかコードを書くのか品質について考えるの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Converting git commit history to a solr full-text index - Gary Sieling
GitHub - garysieling/solr-git: Convert git commit history to solr index
