GitHubとJIRAでリリース管理 - Qiita
どのチームになっても最初に苦労が見えるのはリリース管理だったりします。 次のリリースいつだっけ？ これいつリリースしたっけ？ この機能っていつリリースされるの？ 要件定義からリリースまでのフローとその内容がきっちり管理されていないとよくある話だと思います。 今回は、以前いたチームで数年間運用方法を殆ど変えなかったやり方を紹介します。 うまくいっていたから変えずに済んだのだと今更ながら思ったので。 この記事はサーバーサイドエンジニア目線です。 他の職種の方が見た場合に気分を害すこともあるかと思いますが、悪意は無いので怒らないで優しく指摘してもらえると嬉しいです。 参考にしてもらえると嬉しい方々 短期間で定期的にリリース作業がある(1〜2週間に1回くらい) 機能開発／改善を定常的に行っている 少人数のチーム（だいたい20人位まで） JIRAとGitHub(GHEやGitLab含む)を使っている
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
