問題タブ [release]

Linux/PHP Web サイトの舞台裏で実行される多数のバッチ プロセスがあります。それらは数と複雑さを増し始めているので、少しプロセスを加えたいと思います。

私のソース ツリーには、開発を念頭に置いて整理されていますが、展開を念頭に置いていない cpp ファイルとスクリプトがたくさんあります。すべての実行可能ファイルをコンパイルしたら、さまざまなスクリプトとバイナリをマシンのクラスターに配置する必要があります。マシンが異なれば、バッチ プロセスに必要な実行可能ファイル、スクリプト、および構成ファイルも異なります。また、すべてのマシンに対応するいくつかのツールを作成しました。現時点では、この展開プロセスは手動であり、エラーが発生しやすくなっています。

最終的には、ソース ツリーのルートで実行され、任意のマシンに必要なすべての小さなツリーを構築するスクリプトになるだけだと思います。次に、それを適切なマシンに rsync します。しかし、他の人がこの種の問題をどのように管理しているかに興味があります。何か案は？

新しいバージョンを提供するときのポリシーは、VCS にブランチを作成し、QA チームに処理させることです。後者がゴーサインを出したら、タグを付けて製品をリリースします。テクニカル リリースを作成できるように、ブランチはバグ修正 (のみ) を受信するために保持されます。これらのバグ修正は、その後トランクにマージされます。

この間、トランクは主要な開発作業を見ており、リファクタリングの変更を受ける可能性があります。

問題は、(バグ修正のマージが成功するように) 安定したトランクを持つ必要性と、コードが別のメソッドに抽出された場合や別のクラスに移動された場合、通常はできないこととの間に緊張関係があることです。新しい機能を導入するときにリファクタリングする必要性。

私たちのポリシーは、十分な時間が経過してブランチが十分に安定するまでリファクタリングを行わないことです。この場合、トランクで変更のリファクタリングを開始でき、トランクとブランチの両方でバグ修正を手動でコミットする必要があります。

しかし、これは、開発者がトランクにリファクタリングの変更をコミットする前に、かなりの時間を待たなければならないことを意味します。これは、ブランチからトランクへの後続のマージを中断する可能性があるためです。また、バグをブランチからトランクに手動で移植しなければならないのは苦痛です。これは開発を妨げているように私には思えます...

この緊張をどのように処理しますか？

ありがとう。

リリースしたばかりの企業 Web サイトの更新について、コンテンツ編集者に引き渡す必要があります。どうやら、ノートを使ったトレーニング セッションでは十分ではありません。けっこうだ。

そのため、さらに恐ろしいドキュメントが迫っています。Google でかなり短いトロールを行った後、Web サイトまたは Web アプリケーションのハンドオーバーの基礎として使用する、適切で使用可能なテンプレートを見つけることができませんでした。そのようなドキュメントに表示されるべきであると私が見つけた最も有用なアイテムのリストは、Experts Exchange (敵) にありました。

1. システム概要・総論紹介
2. プロセスと部門間のプロセス フロー
3. システム構成、セットアップ、および依存関係
4. 技術的な要件、機能、制限
5. サポートプロセス
6. トラブルシューティングのための関係者のエスカレーション リストと連絡先情報

これは、作業を行うための優れた基礎です。サイトのコンテンツを変更するだけのユーザーのために「簡単に説明」できますが、クラウドで利用できる優れた標準テンプレートを知っている人はいますか? このリストに追加すべきものは他にありますか?

開発したアプリケーションのソースコードについて、クライアントの専門家をトレーニングする必要があります。ソースコードのトレーニング計画には何を含める必要がありますか？どんな助けでも本当にありがたいです。

よろしく

CommonUtils などの共通プロジェクトのリリースを行うときに依存関係を含める必要がありますか?それとも、使用するときにどの依存関係を参照する必要があるかを単に指定する必要がありますか?

Maven リリース プラグインを使用して、スナップショット プロジェクト 'foo-1.0-SNAPSHOT' をリリースしたいと考えています。このプロジェクトは、まだリリースされていないサードパーティ モジュール「bar-1.0-SNAPSHOT」に依存しています。プロジェクトの pom.xml でオプション 'allowTimestampedSnapshots' を使用して、タイムスタンプ付きのスナップショットを許可していますが、maven が未解決の SNAPSHOT 依存関係について文句を言うので、自分でビルドしない限り、サードパーティ モジュール (バー) にはタイムスタンプが付けられないと想定しています。

依存する SNAPSHOT プロジェクトに関係なく、プロジェクト foo をリリースする方法はありますか?

まさにタイトル通り。MSVC++ 2008 Express を使用していますが、リリース モードでコンパイルするとクラス コンストラクターが実行されません。デバッグモードで動作します。

私は次のようなことをしています:

ブレークポイントはDoIt();トリガーされますが、ブレークポイントはトリガーされClassTest::ClassTest();ません。

クライアントのニーズとより一般的なロードマップのリズムで進化するソフトウェア製品があります。

私たちは SCRUM プロジェクト環境にいるため、新しい機能が製品に導入されることが非常に定期的に発生し、次の選択に直面します。

• この機能をすでにリリースされているブランチに実装する (実際にはブランチを持つポイントではありません)
• 新しいブランチを作成します - しかし、その後、3 週間ごとにブランチを作成し、もはや維持できなくなります

新機能をリリースしないという選択肢はありません。クライアントは、必要な機能を取得するための長期的なマイルストーン計画を待ちたくありません。また、機能をクライアント モジュールに移動することが常に可能であるとは限りません。変更が必要になる場合もあります。商品の核となる...

この種の制約が与えられた場合の優れた実践についてのフィードバックはありますか?

私は他のアプリで使用するライブラリを開発しています。このライブラリには、NLog のおかげで多くのデバッグ ステートメントとログ ステートメントが含まれています。

リリース モードに切り替えるときに、NLog.dll への参照を除外することはできますか?

乾杯、

商用ソフトウェアの早期リリース/頻繁なリリースの経験/例を持っている人はいますか? それは機能しますか？

私は、各メジャー バージョンの間に多くのリビジョン リリースがある VMware を考えていました。また、インストール エクスペリエンスはひどいものでした。既存の VM が壊れたり、ゲスト OS 内の VMware Tools が誤動作したり、インストールされなかったりすることもありました。それはただ恐ろしいです。

ClickOnce を使用すると、ソフトウェアを更新すると、すべてのクライアントにリリースが自動的に通知され、ワンクリックで新しいバージョンに更新されるため、ClickOnce の展開も考えていました。ソフトウェアにバグがある場合、自動的に「アップグレード」されて、それらのバグも取得されます。

早期リリース/頻繁にリリースの原則を商用ソフトウェアに適用する経験\例\提案はありますか?

どれかに当てはめようと思っています。