問題タブ [release-management]

2 つの SQL Server、具体的には SQL Server 2005 の間でデータベースの展開をどのように管理しているのでしょうか。これはビルド スクリプトの一部である必要があるため (標準の Windows バッチ、これらのスクリプトが現在複雑であっても、後で PowerShell に切り替える可能性があります)、Enterprise Manager/Management Studio Express はカウントされません。

.mdf ファイルをコピーして添付していただけませんか? これは互換性の問題のように思われるため、バイナリデータを扱うときは常に少し注意を払っています (開発とライブは常に同じバージョンのサーバーを実行する必要があります)。

または、T-SQL に「EXPLAIN CREATE TABLE」がない場合、既存のデータベースをターゲット サーバーで実行できる SQL スクリプトにエクスポートする何かを行いますか? はいの場合、特定のデータベースを SQL クエリに自動的にダンプでき、コマンド ラインから実行できるツールはありますか? (繰り返しますが、Enterprise Manager/Management Studio Express はカウントされません)。

そして最後に - ライブ データベースに既にデータが含まれているという事実を考えると、デプロイにはすべてのテーブルを作成する必要はなく、代わりに構造の違いをチェックし、ALTER TABLE でライブ テーブルをチェックする必要があります。これには、既存のフィールドが変更されたときにデータの検証/変換も必要になる場合があります。

現在、 Red Gate製品について多くのすばらしい話を耳にしますが、趣味のプロジェクトの場合、価格は少し急です。

では、SQL Server データベースを Test から Live に自動的に展開するために何を使用していますか?

Python は複数のプラットフォームで動作し、デスクトップおよび Web アプリケーションに使用できるため、Mac、Windows、および Linux 用の実行可能ファイルにコンパイルする方法があると結論付けています。

問題は、どこから始めればよいのか、GUI を作成する方法がわからないということです。だれかがこれに光を当てて、正しい方向に向けてください。

標準の Subversion トランク/ブランチ/タグ レイアウトがあります。中長期プロジェクト向けのブランチはいくつかありますが、リリース向けのブランチは今のところありません。これは急速に近づいています。

我々がすべき：

1. リリース ブランチとプロジェクト ブランチを混在させますか?
2. リリース フォルダを作成しますか? もしそうなら、リリースよりも良い名前はありますか?
3. プロジェクト フォルダーを作成し、現在のブランチをそこに移動しますか? もしそうなら、プロジェクトよりも良い名前はありますか? 他のリポジトリで「サンドボックス」と「スパイク」を見てきました。
4. まったく別の何か？

ライブ Web サイトに変更を加える場合、ライブシステムが正しく機能していることをどのように確認しますか? どのツールを使用しますか? 誰がそれをしますか？テスト期間中、サイトへのアクセスをブロックしますか? どのくらいのダウンタイムが許容されますか?

これは少し哲学的な質問です。私は自分のソフトウェアに小さな機能を追加しています。これはほとんどのユーザーが使用すると思いますが、ソフトウェアを使用する回数はおそらく10％にすぎません。言い換えれば、ソフトウェアは3か月間それがなくても問題ありませんでしたが、4〜5人のユーザーがそれを要求しており、私はそれがそこにあるべきであることに同意します。

問題は、私が使用しているプラ​​ットフォームの制限（そしておそらく私の脳の制限）のために、「私ができる最善のこと」にはまだいくつかの重要ではないが顕著なバグがあることです-コード化された機能が使用可能であるとしましょうしかし、場合によっては「少し不安定」です。

何をすべきか？90％ある機能は、本当に「何もないよりはまし」なのだろうか？修正できないバグレポートがいくつか届くと思います。それらについて顧客に何を伝えればよいでしょうか。未回答の機能リクエストまたは未回答のバグレポートを使用する必要がありますか？

私の質問は、どのタイプのプロジェクトにどのバージョン命名スキームを使用する必要があるかということです。

非常に一般的なのは major.minor.fix ですが、これでも数字が 4 になることがあります (つまり、Firefox 2.0.0.16)。一部のモデルでは、奇数が開発者バージョン、偶数が安定版リリースを示します。また、-dev3、-rc1、SP2 など、あらゆる種類の追加機能が混在する可能性があります。

あるスキームを別のスキームより優先する理由はありますか? また、異なるタイプのプロジェクト (つまり、オープン ソースとクローズド ソース) には異なるバージョン命名スキームを使用する必要がありますか?

多数のコンピューターで実行されるJavaサーバーアプリケーションがあります。これらはすべてインターネットに接続されており、一部はファイアウォールの背後にあります。アプリ自体に目立った中断を与えることなく、中央サイトからJARファイルと起動スクリプトをリモートで更新する必要があります。

このプロセスは無人で誰にでもできるものでなければなりません（つまり、インターネットがタイムリーに停止したためにアプリを中断する余裕はありません）。

これまで、さまざまな外部スクリプトとユーティリティを使用して同様のタスクを処理してきましたが、それらには独自の依存関係があるため、結果の保守が難しく、移植性が低くなります。何か新しいものを作る前に、コミュニティから意見を聞きたいと思います。

誰かがこれに対する良い解決策をすでに見つけましたか？何かアイデアや提案がありますか？

明確にするために：このアプリはサーバーですが、Webアプリケーション用ではありません（ここにはWebアプリケーションコンテナーやWARファイルはありません）。これは単なる自律型Javaプログラムです。

私はソフトウェアをオンラインで配布していますが、バージョン番号をより適切に定義する適切な方法があるかどうか常に疑問に思っています。

答えにABCDがあるとしましょう。各コンポーネントをいつ増やしますか?

D mod 2 == 1 など、他のバージョン番号のトリックを使用していますか?これは、社内リリースのみであることを意味しますか?

独自のバージョン番号を持つベータ リリースはありますか、それともバージョン番号ごとのベータ リリースはありますか?

私は製品開発会社で働いています。最初に内部リリースを行い、次に公開リリースを行います。他の製品開発会社がどのようにリリースを管理しているのでしょうか。リリース番号はどのように付けますか？ソース管理にタグを付けますか？

無料で使用できるInstallShieldのようなものはありますか?