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

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になる可能性があります。期限付きのコメントは、これを思い出す良い方法です。
2
build.numberがセマンティックバージョニングの「乱用」なのはなぜですか？
提案されたビルドシステム（Gradle / Artifactory / Jenkins / Chef）をシニアアーキテクトの1人に説明していましたが、彼は私に同意しませんでしたが、実際に計量するのに十分な経験はありませんでした。 このプロジェクトは、他のチームが再利用するアーティファクトとしてJavaライブラリ（JAR）を構築します。バージョン管理には、次のセマンティックアプローチを使用します。 <major>.<minor>.<patch> どこにpatchバグ/緊急フィックスを示し、minor下位互換性リリースを示しており、majorいずれかのAPIの大規模なリファクタリングおよび/または互換性のない変更を示します。 ここでの配信に関しては、私が望むものです。開発者がコードをコミットします。これにより、QA / TEST環境へのビルドがトリガーされます。一部のテストは実行されます（一部は自動化され、一部は手動）。すべてのテストに合格すると、プロダクションビルドがJARを社内リポジトリに公開します。この時点までに、JARは適切にバージョン管理される必要があり、build.numberCIツールによって自動的に生成および提供されるものを使用して、パッチ番号として機能させることを考えていました。 したがって、バージョン管理は実際には次のようになります。 <major>.<minor>.<build.number> ここでも、build.numberCIツールによって提供される場所。 アーキテクトはこれを却下し、CIビルド番号の使用はセマンティックバージョニングの「乱用」であると述べました。 私の質問は次のとおりです。これは正しいですか？もしそうでなければ、なぜですか？
2
VCSにソフトウェアバージョン番号を保存することをお勧めしますか？
などの製品バージョンは、v1.0.0.100ソフトウェアの固有の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終パッケージ/ビルド/バイナリバージョンを維持するための2つの方法があります。 バージョン管理。ファイルはどこかにバージョン番号を保存します。Continuous Integration（CI）ビルドサーバーには、このチェックインバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。 環境および/またはビルドパラメータ。これらはバージョン管理外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは、同じ方法で番号を配布および使用しますが、値の取得方法が異なります（ソースツリーに対する相対位置をスクリプトに知らせるのではなく、ビルドスクリプトに提供されます）。 最初のアプローチの問題は、メインラインのブランチ間でマージが複雑になる可能性があることです。同じソフトウェアの2つの並行リリースを引き続き維持する場合、最後のマージ以降に両方のバージョンが変更されている場合、2つのメインライン間のマージ時に競合を解決します。 2番目のアプローチの問題は、調整です。1年前のリリースに戻ると、タグ情報のみに依存してリリース番号を識別します。 どちらの場合も、CIビルドの前に知られていないバージョン番号の特定の側面があるかもしれません。たとえば、CIビルドは、実際には自動化されたビルド番号である4番目のコンポーネント（たとえば、ブランチ上の140番目のビルド）にプログラムで配置できます。VCSのリビジョン番号でもあります。 ソフトウェアのバージョン番号を把握する最善の方法は何ですか？VCSで「既知の」部品を常に維持する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？ 現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを介してバージョン番号を維持しています。masterブランチにマージする前に、CIビルドの開始前にバージョン番号が適切に設定されていることを注意する必要があります。Gitflowのワークフローに関しては、ソース管理でバージョン番号が追跡されていればrelease、リリースの準備でブランチを作成するときに、バージョン番号が適切に設定されることを保証できると思います。QAは、このブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時に、masterリリースへのコミットメントを示すマージが行われます。
6
連続配信は実際にはどのように機能しますか？
継続的デリバリーは良さそうに聞こえますが、私のソフトウェア開発経験の年は、実際には機能しないことを示唆しています。 （編集：明確にするために、私は常に多くのテストを自動的に実行しています。私のチェックは、各チェックインで自信を得る方法についてです。これは完全な形式のCDであると理解しています。 。毎週（一部は正しく行われればまだCDであると考えるかもしれません）、2週間、または1か月の繰り返しです。 完全なテストカバレッジは不可能です。あなたは多くの時間を費やす必要があります-そして、時間はお金です-すべての小さなもののために。これは貴重ですが、他の方法で品質に貢献するために時間を費やすことができます。 自動的にテストするのが難しいものもあります。たとえば、GUI。Seleniumでさえ、GUIが不安定かどうかはわかりません。かさばるフィクスチャがないと、データベースアクセスをテストするのが難しく、データストレージの奇妙なコーナーケースをカバーすることさえできません。同様に、セキュリティや他の多くのもの。事実上単体テストが可能なのは、ビジネスレイヤーコードのみです。 ビジネス層でも、テスト目的で引数と戻り値を簡単に分離できる単純な関数はありません。モックオブジェクトの作成に多くの時間を費やすことができますが、これは実際の実装とは異なる場合があります。 統合/機能テストは単体テストを補完しますが、通常は各テストでシステム全体を再初期化する必要があるため、実行に時間がかかります。（再初期化しないと、テスト環境に一貫性がなくなります。） リファクタリングまたはその他の変更により、多くのテストが中断されます。それらを修正するのに多くの時間を費やします。意味のある仕様の変更を検証することであれば問題ありませんが、実際には重要な情報を提供するものではなく、意味のない低レベルの実装の詳細のためにテストが中断することがよくあります。多くの場合、微調整は、テスト対象の機能を真に確認することではなく、テストの内部構造を修正することに焦点を当てています。 バグに関するフィールドレポートは、コードの正確なマイクロバージョンと簡単には一致しません。
4
どの時点でリリースビルドに切り替える必要がありますか？
Jez HumbleのContinuous Deliveryで設定されているプラ​​クティスの1つは、1つのパッケージをビルドしてから、展開先の各環境にリリースし、実稼働に移行する前に展開とアーティファクト自体が複数回テストされるようにすることです。 私はこの考えを完全に支持します。 一方、行番号付きのスタックトレースを提供するデバッグモードビルドは、リモートデバッグ機能と同様に、テスト環境で非常に便利です。しかし、リリースビルドを実稼働環境に送信する必要があります。 それでは、最初の原則に従う人々にとって、どの時点でデバッグからリリースビルドに切り替えるのですか？ テスト環境への最初の展開の前に、デバッグモードを失うコストを計算することは、実際のリリース候補を早期にテストするために支払う価値がありますか？または、プロモーションプロセスのある時点で、ソフトウェアを介したビルドプロセスを信頼することを考えて、再度ビルドしますか？それとも、すべてを台無しにして、デバッグバージョンを運用環境に展開するだけですか？ 注：通常、ビルド時にスイッチを設定するのではなく、設定でスイッチをフリックできるため、これはインタープリター言語には実際には適用されません。
2
DB移行およびAzure展開スロット
新しいWebアプリケーションをAzure Web App Service（以前のAzure Webサイト）にプッシュする予定です。展開スロットを利用して、運用環境にプッシュする前に展開をテストできるようにします。DBスキーマの変更が必要ない限り、これで十分です。しかし、スキーマの変更がある場合、同じdbバージョンで動作する2つのソフトウェアバージョンを持つことはできません。EF Migrationsを使用しているため、ステージングスロットへのプッシュにより、即座にDBが最新バージョンに更新されます。 だから私の質問は、データベースの移行が必要なときに展開スロットを使用するかどうかです。 大規模なSaaSプロバイダーではどのように行われますか。彼らは新しいバージョンで即座にDB移行を実行していますか？それは確かにいくつかのダウンタイムを引き起こすでしょう。 この問題のかなり複雑な解決策しか考えられませんが、簡単なものはありますか？
3
ビルド自動化対デプロイ自動化対継続的統合
もっと効率的になりたいし、opsツールを効率的に使いたい。 これを念頭に置いて、私は継続的インテグレーションについてもっと学びたかったのですが、それに関して多くの異なることがあるようです。 私は実際に私の仕事（IntelliJ、WebStorm ...）でJetbrainsスーツを使っているので、それらを使い続けたいと思っていました。 私の問題は、以下の違いがわからないことです。 ビルディングオートメーション（TeamCityはこの種のソフトウェアです）：リモートVCSリポジトリを使用してアプリケーションをビルドできることは知っていますが、それは素晴らしいことですが、その主な目的は何ですか？これを行う際にどのような情報が重要ですか？実際、ソフトウェアがローカルでビルドされているかどうか、チームメートも既に知っています。それでは、自動化を展開せずにそれを使用する目的は何ですか？ 自動化の展開（TeamCityは簡単に実行できないようです） 継続的インテグレーション（上記の2つの組み合わせのようです） 継続的デリバリ（これは正確に何ですか？なぜ継続的インテグレーションと異なるのですか？） これをもう少し理解してもらえますか？
4
機能の半分を実装するための正しいアプローチをどのように学ぶのですか？[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 開発チームを率いて、できるだけ頻繁に製品をリリースしたい（継続的デリバリー）。 多くの場合、リリース間の時間よりも実装に時間がかかる機能を実装する必要があります。私はまだ人々に毎日コードをコミットしてもらいたい（継続的インテグレーション）。 多くの場合、新しい機能を実装するには、既存の機能を変更する必要があり、もちろん、新しい機能がまだ終了していない場合でも、既存の機能を動作させる必要があります。 開発者が適切なアプローチを使用する場合、既存の機能を慎重に調整でき、上記のすべては問題ではありません。 しかし、実際には正しいアプローチは何ですか？私のプログラミングに慣れた心は、個々のケースごとに何をすべきかを教えてくれますが、さらに学ぶ必要があり、読むことができ、チームメンバーに読んでもらうための読み物が必要です。または、このアプローチを学習する正しい方法を学習する他の方法でも実行できます。 それが問題です。機能の半分を実装するための適切なアプローチをチームメンバーに確実に学習させるにはどうすればよいですか？ これに関する戦略を持っていると主張する人々を検索しましたが、トピックについていくつかのランダムな考えを書いている人々を除いて、まだ見つけていません。おそらく、私は正しい検索語を使用していないか、おそらく誰もこれに関する権威あるガイドラインを作成していません。
4
ステージング環境とUAT環境の違いは何ですか？
ソリューションの開発中は、少なくとも3つの異なる環境が必要です。 開発：プログラマはいつでも自由に変更を加えて変更をプッシュし、コードをすばやくテストして他の変更と統合することができます。何も壊す恐れはありません。これはTESTデータベースとサービスに接続されています。 UAT：ハードウェアに関する本番環境の「できるだけ良い」コピーが含まれている必要があるため、開発者は敬意を持って扱う必要があります。ただし、この環境は本番データの編集可能なコピーでUATデータベースに接続されている点が異なります。 Q＆Aチームとユーザーの両方が、本番環境への変更を検証するために使用します 生産：本当の取引。 私はに見てきたソフトウェア工学にこの質問、およびServerFaultの上でこの質問、および彼らがステージング環境の意味は何に異なるように見えます。また、主題に関するウィキペディアのページには、次のように述べられています。 ステージング環境の主な用途は、本番環境に適用する前に、すべてのインストール/構成/移行スクリプトと手順をテストすることです。これにより、本番環境へのすべてのメジャーアップグレードとマイナーアップグレードが、エラーなしで、最小限の時間で確実に完了します。 私にとって、ステージングは​​UATと同じです。UATでは、現実の世界に移行する前に、アプリケーションと展開の手順をテストする必要があります。そのため、本番環境にプッシュするのと同じ方法でUATに変更を加えてパッケージをプッシュします。完全に自動化され、本番環境で必要なすべてのセレモニーが行われます。 とはいえ、UAT環境とステージング環境の適切な違いは何ですか？ - 編集：明確にするために、私はインターネットアプリケーションでもイントラネットウェブサイトでも、Webアプリケーションの観点から考えています。「フォーム」アプリやモバイルアプリはありません。
2
サービスの構成変更をテストする方法は？
新しい構成を追加するときにサービスをテストする最善の方法は何ですか？たとえば、私のサービスは顧客にサービスを提供し、顧客の構成に基づいて、異なるタイプのサービスを提供します。たとえば、顧客が特定の通貨を選択した場合、別の通貨と比較して20％の割引が提供されます。 上記の例は重要ではありません。重要なのは、CI \ CDを行うときに人々がとるアプローチです 割引を計算するロジックはドメイン内にあり、その周りに単体テストがあります。私の質問は、割引を把握するためにさまざまなルールで構成されたマーチャントがいる場合（すべて構成に基づいており、ドメインがそれを解決する場合）、構成を変更する要求が来た場合、どのように確認しますか？ もっとテストを書きますか？ 単体テストと同じようにテストしませんか？ 変更を手動でテストしますか？ その他の 私は多くの記事と共にxUnitテストパターンとテスト駆動開発の本を読みましたが、人々がこれをどのように管理するか（サービス内の構成変更と正確性の検証）に遭遇していません。 私はこれが継続的デリバリー・ブックで扱われるのを見ません。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.