タグ付けされた質問 「continuous-delivery」

ソフトウェアをCIパイプラインの一部として本番環境に手動でデプロイすることに関する質問には、このタグを使用します。本番環境への自動デプロイに関する質問については、[continuous-deployment]タグを使用してください。

4
継続的インテグレーションは、継続的な配信/展開とどのように関係していますか？
これは、continuous-integrationの現在の内容からの引用です： ...統合の問題を防止または最小化するために、開発者の作業コードのコピーを共有コードベースに頻繁にマージするプロセス。 わかった。しかし、その後、継続的な配信と 継続的な展開もあり、それは私が継続的に少し迷子になるところです： どのように継続的な統合はに関連し、連続配信および/または連続展開を経由して行（複数可）に沿ってどこかにいることを想定して、integrationあなたは結局deliveringすべてが可能になるターゲット環境でdeployed。 継続的デリバリーと継続的デプロイメントの違いは何ですか？ 昔、DevOpsがDevOpsと呼ばれる前に、次のような新しいDevOps用語を理解するのに役立つ用語を使用していました。 pre-prodターゲットに昇格（または降格）し、必要に応じて何らかのタイプの再生成プロセス（コンパイル、バインドなど）と組み合わせて、関連するすべてのコンポーネントを実行可能ファイルにまとめます。それは、継続的インテグレーションに似ている/近いはずなのか、そうでないのか？ FTPのようなものを使用してターゲット環境に配布します（標準のコピーがギャップを埋めることができない場合）が、ターゲットでまだアクティブにしないでください。それが連続配信に似ている/近いはずなのか、そうでないのか？ インストール（またはアクティベートそれは近い/類似していなければならないものだなど、）一部のターゲット環境では、バインド、停止/起動操作のようなものと組み合わせて連続展開、かどうか？
6
データベースの継続的な展開を可能にするプラクティスまたはツールは何ですか？
インフラストラクチャとコードの継続的配信または継続的展開は、データベース、特にRDBMSに対して同じアプローチを試みるのに比べて比較的簡単です。コードとインフラストラクチャは、展開が完了しても変更も進化もしません。ただし、データベースには新しいデータが追加され、スキーマが本質的に可変コンポーネントでない場合、データが作成されます。 データベースオブジェクト、つまりテーブルと列のみを追加し、それらを変更または削除しないなどのプラクティスがあることを認識しています。スキーマ。 同様に、FlywayやReady Rollなど、スキーマのバージョン間で記述される移行の記述を支援する製品があります。 現在、データの整合性が懸念される本番環境へのデータベーススキーマの継続的な展開を可能にする他のプラクティスとツールはありますか？
3
機能フラグの切り替えの使用方法
アプリケーションで機能フラグの切り替えを使用するさまざまな方法は何ですか？ 完全に機能フラグが切り替えられたアプリケーションに到達するために行うべき正確なことを開発者に説明する場合、それらの手順はどうなりますか？
3
AWSのシンプルなCI / CDコンテナー
AWS Code Pipeline、Code Buildを使用して新しいDockerコンテナーを作成し、ECRにプッシュしています。 私のアプリケーションは、シンプルで単純な単一コンテナーベースです。現在実行中のコンテナをプルダウンし、ECSレジストリから新しいコンテナを再起動するための摩擦の少ないアプローチ（コードパイプラインを介したコードビルドの出力）。 EC2ユーザーデータを使用してCloudFormationを試し、一方にカスタムスクリプトを、もう一方にECSを使用してCloudFormationを試しました（まだ成功していません）。もっと明確でシンプルなアプローチが必要だと強く感じています。
2
連続配信の最後に手動ステップを実装する方法は？
「についての私の質問への受け入れ答えどのように継続的な統合は、連続配信/展開に関係していますか？」についても説明小さな違いの間に連続的送達と連続展開を。「本番環境にどのようにデプロイしますか。これらは（排他的な）選択可能なオプションです。」のような質問への回答に関連しているようです。 自動（マチック）。 マニュアル。 DevOpsの壁の向こう側に貧弱な「オペレーター」がいることを想像することはできません。 「質問」では、「配布」対「インストール」という参照は、そのような「手動」のものの可能な実装に近いですか？関連する質問の関連する引用は次のとおりです。 FTPのようなものを使用してターゲット環境に配布します（標準のコピーがギャップを埋めることができない場合）が、ターゲットでまだアクティブにしないでください。それが連続配信に似ている/近いはずなのか、そうでないのか？ バインド、停止/開始操作などのようなものと組み合わせて、いくつかのターゲット環境にインストール（またはアクティブ化）します。それは、継続的デプロイメントに似ている/近いはずですか？ 他の可能な実装は何ですか？
1
「Push on Green」とは何ですか？
Googleや他のDevOps組織内で、彼らは「Push on Green」について話します。私は、自動テストの正常な実行に基づく継続的デリバリーの実践であり、おそらくライブ環境への展開であると信じています。 「Push on Green」とは具体的には何ですか、それを適用する意味は何ですか？
1
Elastic BeanstalkはエンタープライズグレードのCDに適していますか？
私はJenkinsを使用してマイクロサービスを構築し、Elastic Beanstalkにデプロイしているプロジェクトで作業しています。統合ブランチをテスト環境にデプロイし、ブランチをステージング環境にリリースしてから、最終的なマスタービルドを本番環境にデプロイします。私はこの方法でそれを行うことにいくつかの懸念があります。最初に、環境ごとにプロジェクトごとに1つのビルドのマトリックスが作成され、作業が重複することを意味します。2つ目は、ステージングで検証されたものと同じビルドアーティファクトを本番環境にデプロイしないことです。 私はBeanstalkを放棄して、デプロイメントにChefのようなものを使用してプレーンなASGに移行する傾向があります。これにより、プロジェクトごとに1つのビルドが作成され、ビルドアーティファクトが生成されます。ステージングで承認されたプロダクションに同じアーティファクトをデプロイできます。ただし、移行の前払いコストはさほど重要ではありません。より信頼性が高く、管理が容易なCI / CDを可能にするBeanstalkをよりよく使用する方法はありますか？ 注：同じビルドアーティファクトをプロモートすることはまさに私がやりたいことですが、ドキュメントからはそれを行う明確な方法がわかりません。アプリソースからEBにデプロイする方法について説明していますが、既存のバージョンを別の環境に昇格させる方法については説明していません。EB自体で使用できる場合、Jenkins EBデプロイメントプラグインに制限があり、それが特にJenkinsで実行できないようになっている可能性がありますが、その方法はまったくわかりません。
2
「真に再現可能なビルド」とは正確には何ですか？
正確には何ですか？継続的デリバリーの分野で、なぜ重要なのですか？ コンテキスト：（私はredditを推測している）のコメントの1つで、Truly Reproducibleビルドはまだ研究中の技術であり、作成するのが非常に難しいと見ました。 それで、なぜそれらを作成することがそれほど難しいのか知りたいのですか？
3
開発者は、プッシュ後にCIパイプラインが完了するのを待つか、次のタスクを開始する必要がありますか
私の会社はCI / CDを統合しています。これまでのところ、私が理解しているものからCIを実装しています。現在、開発者がコードをgitリポジトリにプッシュすると、CIパイプラインが実行されます。 現在、CIパイプラインには、プロジェクトの構築と静的コード分析の実行が含まれており、コーディング標準に適合していることを確認しています。次にテストを実施します。ビルドと静的コードの分析には、現在約3分かかります。私が読んだことからすぐに問題を修正することは、CI / CDにとって重要です。単体テストを追加すると、パイプラインの実行に約10分かかることが予想されます。 したがって、私の質問は、CIパイプラインが完了するのを待つか、次のタスクに進んでパイプラインの問題が存在する場合はそれを修正するためにプル/マージリクエストを行う必要があるかということです。または、座ってパイプラインの実行を監視する必要がありますか？
2
データサイエンスパイプラインとモノリティックモデルblob
通常、DevOpsの重要なトピックの1つは、ソフトウェアアーティファクトの自動作成と配信をどのように処理するかです。 データサイエンスの台頭により、新しいタイプのアーティファクトが存在します。たとえば、訓練されたニューラルネットや他の機械学習モデルを表すモノリティックバイナリブロブです。このようなblobはサイズが数GBになる可能性があり、その作成は組織をCI以前の時代に戻す標準化されたAFAIKにはまだなっていません。それにもかかわらず、彼らは自分のバージョンと関連するトレーニングデータのコレクション（コーパス）を持っています。これらは急速に成長する傾向があります。 DevOpsメソッドを使用してこの新しい課題に対処するためのベストプラクティスは何ですか？
2
複数の環境でデプロイメント（特にデータベースオブジェクトの変更）を同期する方法[複製]
この質問にはすでに回答があります： データベースの継続的な展開を可能にするプラクティスまたはツールは何ですか？ （6つの答え） 5か月前に閉鎖。 私はDevOpsエンジニアであり、数か月前のチームのソフトウェアエンジニアです。開発者は、中央のOracle DBから、個々のラップトップのCentOS VMにDBを持つことに移行しました。中央DBからの移行は、DBAへの依存を減らし、データの不整合に起因する問題を排除することでした。 チームの全員とデータベースの共有と同期を確実にする計画は、各人が全員と変更スクリプトを共有することでした。問題は、Skypeを使用して通信を行うことです（スラックをセットアップするだけですが、まだ完全には使い始めていません）。DB変更スクリプトのテキストが投稿されることもありますが、見落とされる場合があります。もう1つの問題は、一部の開発者が変更の投稿を見逃していることです。さらに、新しいリリースは本番環境にデプロイされ、テストおよびデモ環境にはデプロイされません。 これは私たち、特に最近の私にとって深刻な課題となっており、デモの展開とプロダクションの展開を確実に同期させる責任がありました。同期に関する問題のほとんどは、変更スクリプトがないか、DBオブジェクトがないために、データベースが同期されていないことにあります。Oracleは私たちの好みのDBです。 デモ環境での一般的な展開は、アプリケーションのテストを含む非常に痛みを伴うプロセスであり、DBテーブルの列、関数、ストアドプロシージャの欠落が原因で問題が発生するため、欠落しているDBオブジェクトを探し、それらをDBに適用してから、すべての問題が解決されるまで続行します。 この問題を解決して、スムーズで痛みのない、時間のかからない展開を確実にするにはどうすればよいですか？アプリケーションをDockerに移行すると、DB同期の問題と、それに伴う開発者の規律の欠如を解決できますか？この分野で改善するためにどのようなプロセスを導入できるでしょうか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.