問題タブ [change-management]

あなたのチームのプログラマーは、古いレガシー システムの保守に長けています。しかし、同社は新しいテクノロジー/プラットフォームに切り替えました。

もはや効果のない開発者をどうしますか?

私は現在、メインフレームのチェンジマンでパッケージを宣伝しようとしています。現在、私が従わなければならない一連の呪文があるようです。残念ながら、魔法の呪文を思い出せません。フォローする前に、何が起こっているのかを理解する必要があります。それで、チェンジマンには何が関係していて、次の意味は何ですか：ステージ、チェックアウト、監査、そしてそれらは何をしますか？

変更要求管理ツールとは何か、変更要求がこのツールに送信されるときに何が関係するかを誰かに教えてもらえますか？

liquibaseのクイックスタートに続いて、チェンジセットを作成しました（非常にばかげています:)）

コード：

クリーンなスキーマを作成し、migrateコマンドを起動しました。

Liquibaseは、サポートテーブルdatabasechangelogと..lockを使用してデータベースを作成しました。

変更を追跡するにはどうすればよいですか？新しいcreateTable要素を追加してチェンジセットを変更しましたが、コマンド「update」を試してみると、liquibaseはこれを教えてくれます

だから私はliquibaseを使う方法を理解していないと思います。

誰かが私を正しい方向に向けるかもしれませんか？

ありがとう

私は危険なほど重い Web アプリを立ち上げようとしていますが、QA でサーバーにほぼすべてのものを置いています。私はまだあちこちで修正と変更を行っており、夜間にサーバーのスナップショットを撮っていますが、何かがひどく起こった場合に自分の環境で何が変更されたかを正確に判断できるように、何らかの形で変更管理を行いたいと考えています間違っています（特に私が生産している間）。だから私は興味があります...誰かが良い変更管理アプリ（ウェブまたはその他）について何か提案はありますか? 他のみんなは何をしますか？私はそれを吸い上げてスプレッドシートを使用する必要がありますか？

私の最後の雇用主は、進行中の開発に対処するためにSVNの上に座った精巧なシステムを開発しました:(変更管理）バグ/問題を調べ、バグID番号と（リリース管理）タグをタグ付けしてコミットを行うときにそれらをコミットに関連付けますバグ/問題追跡システムに基づく特定のリリースの一部としてのSVNのアイテム。この2番目の部分には、ユーザー/管理者からサインオフを取得するためのワークフローが関連付けられていました。次に、リリースを行うとき（通常は毎週木曜日の夜）に、コマンドを実行して、タグ付けされたすべてのコードをチェックアウトし、デプロイすることができます。

私の新しい会社ははるかに小規模であり、SVNと直接取引することを意味する場合でも、低コスト/低メンテナンスの同等品を見つけることに興味があります。特に、ゲームの後半でコミットがビルドを壊してしまうことがよくあり、含めることができるものを解きほぐすのは非常に困難になります。（SVNの管理に関する限り、私はブランチよりもタグのアイデアを好む傾向があります。これは、事前の考慮が少なくて済むためですが、そうでないことを確信できてうれしいです。）

リリースのコミットにタグを付け、その後のデプロイメントを行うために、人々は何を使用しますか？WebブラウザからSVNを参照し、リリースの問題/コミットにタグを付けることができるリリースサイクルを管理するための優れたオープンソースソリューションはありますか？私がこれまでに見た中で最高のものはJiraですが、それは非常に大きなツールのように見えます（構成/保守が難しいですか？）。Apache Foundationは、この目的のためにJiraをうまく利用しています（たとえば、Mahoutロードマップを参照してください）。

これを超える一歩を踏み出すと、この同じシステムに継続的インテグレーションも含まれるようになり、各コミットで単体テストを実行できるようになり、各バグ/問題にもこの情報が関連付けられます。

注：stackoverflowには少し関連性のある質問がいくつかありますが、デプロイサイクルとリリース管理のこの側面をカバーするものは何もありません（release-management-in-svn、manage-your-project-life-cycle、およびbestを参照してください）。 -way-to-handle-change-management）。

最近、興味深い問題が発生しました。私は、これを実装するための「最良の」方法（「最良」の特定の値に対して）を考えてきました。

本質的に、これはソースコードに対するメモの追跡の1つです。これにフラグを立てた例は、SLA内のライブで問題を修正することと、これを最もよく達成する方法でした。詳細に立ち入ることなく、バグがあるかどうかわからない多くの場所で使用されている関数を見つけることになりましたが、問題は1つの場所でのみ報告されていました。

SLAを満たすための修正は、共通のコードを微調整してその機能に関係するすべてのものをテストするのではなく、問題が報告された場所にチェックを追加することでした。

興味深い問題は、アップストリームです。「正しい」方法は、元の関数に戻ってチェックし、呼び出されたすべての場所で正しいことを検証し、ライブラリ関数が間違っていると判断した場合は「適切に」変更することです。

問題は、これには時間がかかるため、アップストリームで回避策などが必要になる場合があります。ただし、同じライブラリ関数を呼び出す別の場所で問題が再び発生した場合（たとえば、6か月後）、2つの問題をリンクする簡単な方法はありません。一緒。バグ追跡データベースを検索することはできますが、これが役立つことは保証されていません。「このライブラリ関数はより徹底的なチェックが必要ですが、今すぐ調査する時間はありません」という行に沿って何かを示すメモが追加されているかどうかによって異なります。

だから問題はこれです：開発者の大規模なチーム（30人以上、サポートと進行中の開発の両方のチームに分かれています）内で、ソースコードに対する「付箋」を管理するためにどのような方法を使用しますか？疑わしい関数のソースコードに「これは少し危険かもしれない」というコメントを追加するのですか？

コメントのコミットに関する問題はプロセスの1つです。変更は変更であるため、変更なしの変更（つまり、コメントのみが追加される変更）をコミットすることは理想的ではありません。開発者はコメントを追加する（迷いキーなどを押す）ことでさえ間違いを犯す可能性があるため、実際の変更が行われた場所でのみコミットする方が常に（IMO）優れています。

これで、Wikiを使用してファイルごとのメモを追跡できますが、少なくとも4つのブランチがあり、数百のファイル（SQLオブジェクト、ソースコード、XMLファイルなど）が不足しているため、Wikiは非常に不安定になります。早く。

これは、SCMがサポートできるといいと思います-単なるメモであるが、SCMのバージョン履歴には追加されないファイルに対するメタデータのビット-（たとえば）を実行するときsvn update、または手動で表示することができます表示されました。

すでに解決策があるかもしれませんが、この種の知識共有をどのように管理しますか？

DBGhostを使用してデータベースの開発と展開のプロセスを再構築することを考えています。中央の開発データベースから離れて、データベースをソース管理に移行したいと考えています。
私たちが抱えている問題の1つは、静的データ（翻訳された言語文字列を含む）を含む大きなテーブルで、20万行近くあります。
私たちの最善の解決策はこれらの刺し傷をリソースファイルに移動することですが、それを実装するまで、DbGhostはこのすべての静的データを維持し、開発および展開データベースを短時間で生成できますか？そうでない場合は、必要なときにこのテーブルを埋める代わりの良い方法はありますか？

多くの開発者によってさらに開発/開発されるデータベースを構築および維持することは、ソフトウェア開発で常に行われていることです。ビルドスクリプトを作成し、データベースが時間の経過とともに大きくなるにつれて適用される更新スクリプトをさらに維持します。これを管理するには、手動更新から、これらのプロセスの自動化に役立つコンソールアプリ/ビルドスクリプトまで、さまざまな方法があります。

これらのプロセスを構築/管理した人は、データベーススキーマ管理用のソース管理ソリューションに移行しましたか？もしそうなら、彼らは何が最善の解決策であると考えましたか？避けるべき落とし穴はありますか？

Red GateはMSSQLの世界で大きな役割を果たしているようで、DBソース管理は非常に興味深いものに見えます：http： //www.red-gate.com/products/solutions_for_sql/database_version_control.htm

（デフォルトの）データ*管理プロセスを置き換えるようには見えませんが、私の視点からの変更管理プロセスの半分を置き換えるだけです。

（私がデータについて話しているとき、私はルックアップ値とその種のもの、デフォルトまたはDRシナリオで展開される必要があるデータを意味します）

私たちは.Net/MSSQL環境で作業していますが、前提はすべての言語で同じであると確信しています。