タグ付けされた質問 「deployment」

展開とは、ソフトウェアシステムを使用可能にするすべてのアクティビティです。ソフトウェアの配備に関する質問は、このタグの下にあります。

7
専用ビルドマシンの目的は何ですか？
前回のビルドサイクルが不十分な展開につながる多くの状況のた​​め、私はオフィスでキャンペーンを行い、専用のビルドマシンを使用して将来のすべての展開を実行し、上司はこの提案を受け入れました。 ただし、オフィスで実際のマシンを使用する代わりに、1台のマシンを他の複数のグループと共有する必要があります。また、必要な情報をすべて入力してオフィスを出て階段を降りる手間がかかります。単純なビルドを実行するためだけに別のオフィスに移動することは、なぜ私が最初にこれを提案したのか疑問に思います。 別個のビルドマシンを使用するというアイデアは、元々、自分のローカルで記述されたコードを他の複数の開発者のコ​​ードから分離し、マシン上にあったハイジャックされたファイルを展開から分離することでした。また、ClearCaseファイル管理システムに対する懸念の高まりを解決することも目的でした。これは、「依存関係がある」別のアクティビティも含めない限り、特定のビルドアクティビティの展開を拒否することがよくあります。 実際にこのプロセスを進めているので、ビルドマシンを使用する目的全体を誤解していないかどうか、そしてこのマシンをテスト、ステージング、および実稼働環境へのコード展開にのみ使用しているため、私たちの個人的な開発者テストの展開ではなく、それが何らかの目的に役立つかどうかはわかりません。 それでは、ビルドマシンを使用する実際の理由は何ですか？また、正しく使用することに近づいていますか？
4
Unixバイナリに近い他の言語と比較して、Javaを使用する場合、Dockerを使用する開発上の利点は無効になりますか？
私は言った友人がいました： Dockerは素晴らしいです。これを使用して、本番環境とそのすべての癖をローカルマシンに複製できます。その後、すべてのステージングワークフローを介して、そのインスタンスを超高速で直接展開できます。 これは、開発者がRuby、PHP、またはGoを記述している場合に当てはまります。オペレーティングシステムへの方向バイナリリンクがありました。 ただし、Javaを使用する場合は、オペレーティングシステムと言語の間に仮想層が既に存在するため、基盤となるオペレーティングシステムに関係なく、操作の一貫性が保たれます。 おそらく、この場合、開発者がローカルで運用環境を複製するためにDockerを実行する利点は無効になります。（Ruby、PHP、またはGoと比較）。 私はこれについて議論することを受け入れており、反対の見解を（証拠とともに）聞きたいと思っています。 Unixバイナリに近い他の言語と比較して、Javaを使用する場合、Dockerを使用する開発上の利点は無効になりますか？
53 java  deployment  jvm  docker 
7
期限付きのTODOコメント？
バックグラウンド 私は、ゼロダウンタイム展開の実装を検討しているチームで働いています。これを実現するために、ブルー/グリーン展開戦略の使用を計画しています。研究を行う上で私が理解していることの1つは、データベースの変更を行うことがどれほど複雑になるかです。カラムの名前を変更するなどの簡単な操作は、完了するまで3回の完全なリリースサイクルを必要とします。 変更の完全なロールアウトに複数のリリースサイクルがかかると、ヒューマンエラーが発生する可能性が大きくなるように思えます。リンクされた記事では、2つのリリースにはコードの変更が必要であり、3つのリリースにはデータベースの移行が必要であることを示しています。 私が探しているもの 現在、何かを行うことを覚えている場合は、問題管理システムでチケットを作成できます。または、TODOコメントを作成することもできますが、おそらく完全に忘れられます。 私が探しているのは、TODOコメントに期限があり、この期限が切れた場合、継続的インテグレーションシステム（現在使用する未定）がビルドを拒否する方法です。 たとえば、列の名前を変更する場合、最初の移行を作成し、次に2つのTODOコメントを作成して、残りの2つの移行が作成されるようにします。 // TODO by v55: Create migration to move constraints to new column, remove references to old column in app // TODO by v56: Create migration to drop old column これは実装するのはかなり簡単に思えますが、車輪の再発明をしたくないので、このようなものがすでに存在するかどうか疑問に思っています。 追加の考え ローリングデプロイメントとブルー/グリーンデプロイメントがベストプラクティスであると考えられるため、ここでXYの問題に苦しんでいるように感じます。データベースの更新の痛みを軽減するソリューションを見つけることができないのは奇妙に思えます。私が間違っていることを完全に調査していると思われる場合は、コメントでお知らせください！とはいえ、私が挙げたデータベースの例はほんの一例に過ぎず、期日付きのTODOコメントは他の状況でも役立つと思うので、この特定の状況に近づいていたとしても、私は本当に自分の答えにしたい実際の質問も。ありがとう！ 編集：これが役立つ別の状況を考えました。機能のトグルを使用して、準備ができたときにアプリの一部を有効にする場合、それらをクリーンアップするように注意する必要があります。そうしないと、Toggle Debtになる可能性があります。期限付きのコメントは、これを思い出す良い方法です。
4
ゼロダウンタイム展開の実現
停止時間ゼロの展開を達成しようとしているので、理論的には、営業時間外に少なく、「遅い」時間にもっと多く展開できます。 私の現在のセットアップ、やや単純化された： WebサーバーA（.NETアプリ） WebサーバーB（.NETアプリ） データベースサーバー（SQL Server） 私の現在の展開プロセス： WebサーバーAとBの両方のサイトを「停止」する デプロイされているアプリのバージョンのデータベーススキーマをアップグレードする WebサーバーAを更新する WebサーバーBを更新する すべてをオンラインに戻す 現在の問題 これにより、毎月わずかなダウンタイムが発生します（約30分）。私は休み時間にこれを行うので、それは大きな問題ではありません-しかし、それは私が逃げたいものです。 また-実際に「戻る」方法はありません。通常、ロールバックDBスクリプトは作成せず、スクリプトのみをアップグレードします。 ロードバランサーの活用 一度に1つのWebサーバーをアップグレードできるようになりたいです。WebサーバーAをロードバランサーから取り出してアップグレードし、オンラインに戻し、WebサーバーBについて繰り返します。 問題はデータベースです。私のソフトウェアの各バージョンは、異なるバージョンのデータベースに対して実行する必要があります-だから私は一種の「スタック」です。 可能な解決策 私が検討している現在の解決策は、次のルールを採用しています： データベーステーブルを削除しないでください。 データベース列を削除しないでください。 データベース列の名前を変更しないでください。 列を並べ替えないでください。 すべてのストアドプロシージャはバージョン管理する必要があります。 意味-「spFindAllThings」は、編集時に「spFindAllThings_2」になります。 その後、再度編集すると「spFindAllThings_3」になります。 同じルールがビューに適用されます。 一方、これは少し極端に思えます-私はそれが問題を解決すると思います。アプリケーションの各バージョンは、中断することなくDBにヒットします。コードは、ビュー/ストアドプロシージャから特定の結果を予期します。これにより、その「契約」が有効になります。問題は、それがただずさんに染み込んでいるということです。アプリがしばらく展開された後、古いストアドプロシージャをクリーンアップできることは知っていますが、それは単に汚い感じです。また、これはこれらのルールに従っているすべての開発者に依存しますが、ほとんどの場合これは起こりますが、誰かが間違いを犯すと思います。 最後に-私の質問 これはずさんですか、それともハックですか？ 他の誰かがこれをやっていますか？ 他の人はこの問題をどのように解決していますか？
15
極度の不安を感じることなく、本番の展開を自動化するにはどうすればよいですか？
当店では、ソース管理にSVNを、CIにCruiseControlを使用して、開発、テスト、および統合環境への自動ビルドと展開を処理しています。 これはすべてスムーズに機能しますが、ハードウェアとリソースの制約により、統合環境は運用環境のような2サーバーの負荷分散環境ではありません。それ以外はすべて同じですが、それが統合環境と実稼働環境の唯一の違いです（ただし、大きな環境です！） 理論的には、違いはアプリサーバーのわずかに異なる構成であり、デプロイスクリプトはビルドアーティファクトを1つだけではなく2つのサーバーにドロップするだけでよいのですが、なぜ本番デプロイを自動化するのにそんなに緊張するのでしょうか？！ 私は一般的にコントロールマニアではありませんが、手作業でプロダクションにプロダクションを展開する必要性を常に感じています。私はこれが一般的に本当に悪いこと™であると同僚から聞いたが、彼らはそれに対して主張をすることに失敗した。 手動で行うと、正しいファイルを物理的にコピーしていること、アプリサーバーを物理的にシャットダウンし、正常に終了したことを確認できます。正常に起動し、展開が成功したことを確認してください。それは私に心の安らぎを与えます。 自動スクリプト化された運用展開のこのOR引数に対する引数は何ですか？
7
ファイルごとにプロジェクトを手動でサーバーにデプロイするのがベストプラクティスですか？
私が今働いている会社は、継続的デリバリーをまだ実装していません。ファイルごとにサーバーにプロジェクトを手動でデプロイします。ベストプラクティスは次のとおりです。展開ごとに1つのプロジェクトアーティファクトを手動で展開するか、ファイルごとの展開を続けますか？
10
コードを変更してライブWebサイトを更新するにはどうすればよいですか？
これは非常に基本的な質問です。誰かが私にユーモアを与え、彼らがこれをどのように処理するかを教えてくれたら、私はとてもうれしいです。 SynchToyをインストールして以下の問題を修正しようとしているため、これを投稿することにしました。 この状況にいると、何度も痛みを伴う明白な方法を見逃しています。これは、会社で唯一の開発者であることに起因しています。 職場のコンピューターで開発されたASP.NET Webアプリケーション ソリューションには2つのプロジェクトがあります。 ウェブサイト（ファイル） WebsiteLib（C＃/ dll） Gitリポジトリを使用する GoGrid 2008R2 Webサーバーに展開 展開： コードを変更します。 Gitにプッシュします。 サーバーへのリモートデスクトップ。 Gitからプルします。 Windowsエクスプローラーでドラッグ/ドロップして、ライブファイルを上書きします。 ステップ5では、Webサイトのルートからすべてのファイルを削除します。これは良いことではありません。だから、SynchToyをインストールしようとしています... 更新：すべての有用な応答に感謝します。答えをマークするものを選択することはできません-Web展開を使用する間に-いくつかの有用な提案があるように見えます： Webプロジェクト=単一のDLLにパッケージ化されたサイト全体-単純な更新をプッシュすることはできません-50人の会社の孤独な開発者であるため、これは時々より単純なもののままです。 SCMからサイトのWebルートに直接移動します-私はもともと、SCMの隠しディレクトリが公開されることを恐れてこれをしませんでしたが、ここでの回答はそれを乗り越えるのに役立ちました（私はまだ1確認するのを忘れることを心配することは、時間の経過とともにまだ真実です） Webファームを使用し、ノードに体系的に展開する-これは、ダウンタイムがゼロの理想的なソリューションです。これは、サイトが本質的に会社のリアルタイムの収益源であるため、実際に私が気にしていることです。ただし、サーバーのコストは2倍になります。 ->最後に、サイトのシングルクリック展開が必要であるか、または他に何か間違っている必要があるという基本原則の強化は、おそらく私が答えから得た最も有用なものです。 更新2：私はこれに戻って、今何ヶ月もの間存在し、完全に機能している実際のソリューションで更新すると思った（私の単一のWebサーバーソリューション）。 私が使用するプロセスは次のとおりです。 コードを変更する Gitにプッシュ サーバーへのリモートデスクトップ Gitからプル 次のバッチスクリプトを実行します。 cd C：\ Users \ Administrator ％systemroot％\ system32 \ inetsrv \ appcmd.exe停止サイト "/site.name:Default Web Site" robocopy Documents \ code …
2
.Netで複数の重複するソリューション/プロジェクトを構成する方法は？
私は最近、複数の.netソリューションがあり、それぞれがそのソリューションに固有のいくつかのプロジェクトをホストしているが、他のプロジェクトを「借りる」/「リンクする」（既存のプロジェクトを追加する）古いレガシーコードベースを持つ新しいクライアントで働き始めました技術的には他のソリューションに属します（少なくともTFSのフォルダー構造を使用する場合） これが絡み合ったセットアップを見たことはなく、明確なビルド順序はなく、ソリューションAのプロジェクトはソリューションBでホストされているプロジェクトの出力ディレクトリから直接DLLを参照する場合があり、プロジェクトが存在する場合でもプロジェクトが直接含まれている場合がありますフォルダー構造で遠ざかります。 すべてが開発者の怠lazのために最適化されているようです。 CIサーバーを持っていない理由について私が彼らに立ち向かったとき、彼らはそのように組織されたコードでセットアップするのは難しいと答えました。（私は今それを設定し、このコード編成を呪っている） ソリューションは展開アーティファクト（一緒に展開する必要があるものは同じソリューション内にあります）を中心に編成されていますが、賢明な決定だと思いますが、それらのソリューション（プロジェクト）の内容はいたるところにあります。 複数のソリューション/展開アーティファクトで共通のクラスライブラリを再利用するときに使用するベストプラクティスのコンセンサスはありますか、 VCSでコードを構造化する方法 個別のデプロイメントアーティファクト間でビジネスロジックの共有を促進する方法
5
バグを修正するためにソースコードをリリースすべきですか
作成中のアプリケーションにバグがあります。SOについて質問したところ、ユーザーの1人がすべてのコードを投稿または送信して、彼がそれを見ることができるように頼みました。 リクエストを完全に理解しています。それは有効で理解できます。しかし、私はそうすべきかどうか疑問に思っています。明らかに、私は彼/彼女に王国への鍵を与えます、そして彼/彼女が悪意のあることをするならば、私は頼りになりません。 私はまた、彼らの助けを提供したSOのユーザーに無礼を意味しないことを付け加えたいと思います。私はただ懸念を放映しています。 バグを修正したいのですが、この人がそれを修正できるという保証はありません。 ソースコード全体をリリースし、ベストを期待すべきですか？それとも、それを保持し、自分でそれを理解しようとしますか？ あなたならどうしますか？
2
DB移行およびAzure展開スロット
新しいWebアプリケーションをAzure Web App Service（以前のAzure Webサイト）にプッシュする予定です。展開スロットを利用して、運用環境にプッシュする前に展開をテストできるようにします。DBスキーマの変更が必要ない限り、これで十分です。しかし、スキーマの変更がある場合、同じdbバージョンで動作する2つのソフトウェアバージョンを持つことはできません。EF Migrationsを使用しているため、ステージングスロットへのプッシュにより、即座にDBが最新バージョンに更新されます。 だから私の質問は、データベースの移行が必要なときに展開スロットを使用するかどうかです。 大規模なSaaSプロバイダーではどのように行われますか。彼らは新しいバージョンで即座にDB移行を実行していますか？それは確かにいくつかのダウンタイムを引き起こすでしょう。 この問題のかなり複雑な解決策しか考えられませんが、簡単なものはありますか？
4
内部ビジネスアプリケーション用のWindowsインストーラーは理にかなっていますか？
私は、この状況でよくあることについて一般的な理解を深めようとしています。 次のような典型的な企業環境でインストーラーは歓迎されますか？ 変更管理プロセス 開発/ QA /本番環境 さまざまな領域（ファイアウォール、データベース、ウィンドウなど）に指定された展開チーム。 インストーラーの作成に適しているかどうかを確認するために、アプリケーションに適用できる「リトマステスト」はありますか？* インストーラーはシンプルで、すべてのアプリケーションにインストーラーが必要ですか？ インストーラーも適切なツールですか？ 開発者がインストーラーをサポートするためにWiXのようなものを学ぶことを期待するのは合理的ですか？ 一般的に保守性は懸念事項です。つまり、インストーラーを作成することはニッチなスキルですか？ * たとえば、運用サーバーの共有ディレクトリにある一連のwinformアプリケーションがあります。特定のグループはこのディレクトリからアプリケーションを実行できますが、システム管理者のみが実行可能ファイルを変更できます。現在の展開プロセスでは、管理者が実行可能ファイルとライブラリを共有ディレクトリにコピー/貼り付けします。 アプリケーションは個々のユーザーのマシンにインストールされないため、これらのアプリケーションの新しいバージョンを共有ディレクトリに展開するためのインストーラーを作成するのは理にかなっていますか？ 編集- ここでの答えは確かなアドバイスを与えると感じたので、多数のアプリケーションを構築して個々のフォルダーに展開する必要がある現在のプロジェクトで思いついたことを共有したいと思いました。 Webプロジェクトの_PublishedWebsitesの動作を模倣する_PublishedApplicationsというNuGetパッケージを見つけました。NuGetパッケージをプロジェクトにインストールすると、ビルドアーティファクトを出力パスの_PublishedApplicationsディレクトリにコピーするターゲットが追加されます。この動作は、コマンドラインからMSBuildを実行し、outdirプロパティを指定することでアクティブになります。 msbuild /p:Configuration=Release /p:outdir=C:\path\to\outdir MySolution.sln これにより、次のようなディレクトリ構造が得られます。 C：\ path \ to \ outdir _PublishedApplications \ Project1 \ dlls, exes, etc. Project2 \ ... そこから、さまざまな環境で抽出できるzipを作成するのは非常に簡単です。
2
ゼロダウンタイム展開-移行Dbスキーマ
ゼロダウンタイムの展開の実現には同じ問題が関係していましたが、検討している戦略に関するアドバイスが必要です。 環境 サーバー側の処理にApache / PHPを使用し、永続性にMySQL DB / filesystemを使用するWebベースのアプリケーション。 現在、インフラストラクチャを構築しています。すべてのネットワークハードウェアには冗長性があり、すべてのメインネットワークケーブルは、フォールトトレランスのためにボンディングペアで使用されます。サーバーは、ハードウェアフォールトトレランス用の高可用性ペアとして構成されており、仮想マシンのフォールトトレランスと一般的なパフォーマンスの両方で負荷分散されます。 私は、ダウンタイムなしでアプリケーションに更新を適用できることを意図しています。100％の稼働時間を提供できるように、インフラストラクチャを設計する際に多大な苦労をしました。更新が適用されるたびに10〜15分のダウンタイムが発生するのは非常に残念です。これは、リリースサイクルを非常に高速にすることを意図しているため、特に重要です（1日あたり1つ以上のリリースに達することがあります）。 ネットワークトポロジー これはネットワークの要約です： Load Balancer |----------------------------| / / \ \ / / \ \ | Web Server | DB Server | Web Server | DB Server | |-------------------------|-------------------------| | Host-1 | Host-2 | Host-1 | Host-2 | |-------------------------|-------------------------| Node A \ …
3
各環境にあるコードのバージョンをどのように追跡できますか？
私のチームは現在、次のような非常に単純な分岐/展開プロセスを使用しています。 ┌────────┐ ┌────┐ ┌──────┐ Environments: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Builds: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Branches: │ …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.