Microsoft SQL Serverの開発（およびそれだけではありません）：バージョン管理、継続的統合、および手順-方法

こんにちは、ハブロフチャン。



簡単な背景として：1年前、データベース開発部門の責任者（Microsoft SQL Serverに基づく）として新しい仕事に就いたとき、私は見たものから最も深いショックを経験しました。 大企業、複雑なWebアプリケーション、数百万ドルの契約、および開発が本番データベースで実行され、バグレポートが受信され、「誰が大声で叫ぶ」または「昨日すぐに行わなければならない」という方法に従って処理されます。 当然、バージョン管理システム、継続的インテグレーション、手順、ワークフローについての話はありませんでした。



今日、状況は大きく変わりました（ 私がだましている人はちょうど変わり始めています ）が、現在使用しているソリューションの技術的および手順的な詳細を共有したいと思います。 90％の技術的な詳細はMicrosoft SQL Serverの開発に直接関係していますが、手順の変更は私たちとWeb開発者、エンジニア、アナリスト、テスターに​​影響を与えています。



すぐに予約しますが、私は記事で言及するソフトウェア製品の会社/広告主の代表ではありません。 使用するソフトウェアの選択は、機能、価格の点で私たちのタスクに最も適しており、個人的な好みも満たしていました。



詳細に興味のある方-猫へようこそ。

警告：多くのテキスト、手順とプロセスの説明（ 誰も興味がないかもしれません ）。

バグ追跡、プロジェクト計画、追跡

アトラシアンJIRAに基づくソリューションがアプリケーションアカウンティングシステムとして選択されました。 主な理由は次のとおりです。この記事で言及される他の製品との緊密な統合。 アジャイル開発方法論に関する非常に便利な作業。 プロセスのカスタマイズと自動化の幅広い可能性。



私たちは、2週間のアジャイルスプリントに固執することに決め、事前に3スプリント（1.5か月）の開発とテストの計画を立てました。 以下のプロセスの詳細について。

バージョン管理システム

私はアトラシアン製品のファンです。 バージョン管理システムには、Atlassian Stash（Git）を選択しました。 しかし、分岐分岐の使用、分岐のマージ、およびデータベースコードの開発プロセスでのGitのその他の利点は見つかりませんでした。 すべてのコミットはmasterブランチで発生します。



コミットには、RedGateソース管理製品（SSMSのプラグイン）を使用します。 ここで、最初の技術的な困難に直面しました。コードをコミットするだけでなく、SSMSの[コミット]ボタンを押してリポジトリにプッシュすることを望みました。 これは、共有データベースでの開発の観点から正当化されます。 開発が進行中（ストアドプロシージャコードの変更、テーブル構造の変更）、変更はデータベース自体に保存されます。 開発が完了したら、ソース管理でコードを確認する必要があります。 ご存知のように、Gitでの作業はローカルリポジトリで行われ、そこから変更がリポジトリにプッシュされます。 残念ながら、RedGate SCは箱から出してプッシュする方法を知りません。



この制限を回避するために、プルおよびコミットフックとして使用されるRedGate用の2つのバットスクリプトが作成されました。 開発者がプラグインウィンドウで変更のリストを更新すると、プルが実行され、開発者のステーションのリポジトリはリポジトリの現在の状態と同一になります。 そのため、コミットのリストには、データベースには存在するがバージョン管理システムには存在しない変更のみがあります。



コミットする変更（ストアドプロシージャやテーブルなど）を選択して[コミット]ボタンをクリックすると、変更はローカルリポジトリに移動し、その後Gitでプッシュが自動的に行われます。



RedGateソース管理構成ファイルと、その中で使用されるpull.batおよびcommit.batのソースを同封します。









ご覧のとおり、Stash / Gitの操作は、キー認証を使用してSSHを介して行われます。 Red-Gateの初期構成は文書化されており、実際には2つのステップがあります。プラグインをインストールし、初期構成スクリプトを実行します（ユーザープロファイルに必要なフォルダーを作成し、リポジトリの最初のクローンを作成します）。

開発とテストのプロセス

開発者向けのワークフローの構築方法を中断する価値があると思います。 JIRAの助けを借りてプロセスのすべてのステップが強制されるという事実に注意を喚起したいと思います。JIRAでは、ある状態から別の状態への移行を実行する可能性または不可能性を判断するためにさまざまな条件もチェックされます。



通常、プロセスはJIRAで課題を作成することから始まります。 これは、バグレポート、新しい機能の要求、既存の機能の変更、またはアイデアです。 選択したコンポーネント、タイプの問題、および期日に応じて、このチケットが優先されます。 その後、彼は計画キューに入ります。 計画キューで優先度の高い問題は24〜48時間以内にレビューおよび計画され、残りはチーム会議で週に1回です。



「計画」とは、タスクの複雑さと段階、必要な文書の量を決定し、アプリケーションを受け取った人と通信し（詳細を明確にするため）、この問題の解決策をどのアジャイルスプリントに配置するかを決定することを意味します。



このようなプロセスには、タスクを完了するために必要な時間枠の必須の予備評価が必要です。 すべての開発者が週33時間忙しいように、スプリントを構築しようとしています。 残りの7時間は、別の開発者が病気休暇/休暇に入ったときの緊急のタスク、会議、および状況への反応のバッファーとして残されています。



現在/将来のスプリントの「オーバーフロー」が発生した場合、後日まで延期できるタスクを決定する必要があります。 同様に、開発者がスプリント中に仕事をしなかった場合、次のウィンドウにスケジュールされたタスクを移動して開始することができます。



タスクは次のステータスになります。

• 計画（トリアージ）;
• 失敗（拒否）;
• 開発の準備ができています。
• プロセスの開発（開発中）;
• 待機（障害-開発を継続するための障害 ）;
• テスト準備完了（QA準備完了）;
• リリース準備完了（本番準備完了）;
• クローズ（解決済み）;

ステータス間でのタスクの移動は、次のスキームに従ってのみ可能です。



動きが発生する状況は図で説明されています（ただし、英語ではありますが、読者にとって理解は問題ないと思います）。 ダイアグラムに表示されていないものについてお話しします。

1. 大規模なタスクはサブタスクに分割されます。 親の問題は、「開発準備完了」、「開発開始」、および「障害」以外のステータスにはなりません。
2. 開発者がコミットするとすぐに、このコミットのコードレビューが作成されます（ これがどのように起こるかについては以下を参照してください ）。
3. コメントにJIRAチケットへのリンクがある場合にのみコミットを行うことができます。これにより、コミットとその後のレビューが問題に自動的にリンクされます。
4. 開発プロセスの一部としてコードレビューを検討することにしました。そのため、レビューの進行中にチケットは「開発の準備完了/開発が開始されました。 チケットを「Ready for QA」に移動し、さらにレビューが開いている間にチケットを閉じることは不可能です。
5. 「ブロッキング」タスクがあるために問題の解決が不可能な場合、JIRAの対応するリンクが使用されます。 ブロッキングチケットがクローズされるまで、問題のステータスは「Impediment」になり、クローズすることはできません。
6. はい、はい、あなたは正しく理解し、タスクは再開されません。 リリース後にバグ/問題を検出した場合、新しい問題が作成され、以前の問題にリンクします。
7. 課題がクローズされた後-スプリントがクローズされると、その変更が戦闘ベースに自動的に適用されます（ これがどのように発生するか-以下でも ）。

短い余談：説明されたプロセスは、IEEE開発標準と互換性があります。

コードレビュー

コードの変更を確認するためのソリューションとして、アトラシアン（本当に？！） Fisheye / Crucibleを使用します。 JIRAおよびStashとの完全な統合により、問題ページから関連するコミットおよびコードレビューの表示にすばやく切り替えることができます。 JIRA + Stash + Crucible / Fisheyeの統合にはトリックはないため、このトピックについて説明することはありません。

継続的インテグレーション

私の意見では、これは私たちのプロセスの最も興味深い部分です（データベースに関して）。 前述のように、共有データベースを使用し、合計で、開発、テスト/ QA、および本番の3つの別々の環境が使用されます。



開発データベースには、常に最新バージョンがあります。 開発者はコードとそのスキームを絶えず変更しています。 このデータベースにアクセスするフロントエンドアプリケーションも絶えず更新されます（Web開発者がローカルで（エラーなしで）新しい機能/修正を含むビルドをビルドすると、すぐに公開されます）。



DEVへのすべての変更はQAで公開されます。 しかし、「すべて」と言って-私はcです。 ソース管理でコミットされた変更のみが公開されます（まだ「開発中」であるものは公開しません）。 そのため、スキームの通常の同期の代わりに、RedGate SQL CIとビルドサーバーであるAtlassian Bambooの機能を使用します。



Bambooは、SQL CIを呼び出すMSBuildプランを作成しました。 コミットSQL CIがALTERおよびCREATEコマンドを生成するとすぐに、それらをQAデータベースにロールします。



「真の」継続的インテグレーションは本番環境での変更の公開と同じと見なされるべきであることは知っていますが、そうする勇気はありません。 代わりに、RedGate SQL Compareを使用して、スプリントを閉じるときにスキーマをQAと同期します。 したがって、プロセスの観点から見ると、私たちのQAベースは生産です。 ただし、これにより、このプロセスを使用してデータベースを開発するときに使用するアプローチが変更されることはありません。致命的な（破損）変更はありません。 WebアプリケーションのデータベースとしてのMicrosoft SQL Serverの世界では、これは、プロシージャの発行バージョンが正しく終了し、デッドロックを引き起こさないことを意味します。 もちろん、これにはWebアプリケーションの適切なアーキテクチャが必要です。すべての要求はストアドプロシージャを介して実行され、クラスはプロシージャの予想されるパラメータの不在、またはそれ以上をサポートする必要があります。 プロシージャはNULLパラメータをサポートし、セキュリティリスクを発生させずにそのような状況に応じて対応する必要があります。 私たちの場合、これは可能だと思われます。

おわりに

私が説明したシナリオは非常に具体的であり、他の条件ではその適用が不可能であることを理解しています。 ただし、コミュニティと経験を共有するためにこれを書きました。また、誰かに新しいツールを紹介したり、誰かの開発プロセスを確認する機会を与えたりすることを望んでいます。このアプローチは、より有能で論理的です。 もっと多くのことを伝えたかった-自動化されたテスト（自動化された単体テストと統合テスト）がこのプロセスにどのように配置され統合されているか、QAプロセスにMicrosoft Data Quality Servicesを使用する方法、ドキュメントがどのように編成されているかについてですが、テキストが多すぎます 多分私は別の記事でそれをするでしょう。 それまでの間、私は質問と建設的な批判に喜んでいるでしょう。