プロジェクトを手動で公開していますか？それから私たちはあなたに行きます

カットラインの下で、以下を含む.NETプロジェクトのCIをゼロから実装するためのガイドライン：

毎日の自動ビルド
問題通知
バグ追跡システムおよびバージョン管理システムとの統合
製品のバージョン管理
データベースのバージョン管理
自動計算とバックアップ

まず、「継続的インテグレーション」とは何ですか？

継続的インテグレーション（Eng。継続的インテグレーション）-これはソフトウェア開発のプラクティスであり、プロジェクトの頻繁に自動化されたアセンブリを実装して、インテグレーションの問題を迅速に特定して解決します。

実用的な観点からは、これは、いつでもテストまたは実証できる「製品の現在の最新バージョン」が必要であることを意味します。

これを行うには、次のものが必要です。

開発者がコードを少なくとも毎日VCSに提供するように
製品の組み立ては自動的に行われました
製品の表示（データベースの更新を含む）が自動的に行われました
製品テストは自動で行われました（可能な限り）

継続的インテグレーションとは、アジャイルプラクティスを指します。アジャイルは、開発、テスト、製品開発のサイクルを繰り返し繰り返す反復プロセスを伴います。ルーチンプロセスの自動化により、複数のルーチン操作が回避されます。

VCSを使用する

まず、アプリケーションをテストするためのテスト環境が必要です。テストサイクルが十分に長く、開発が速い場合は、開発環境も強調するのが理にかなっています。 VCS構造は周囲を反映します。

すべての開発者はメインの開発ブランチで作業し、特定のバージョンが修正されてテストブランチにマージされます。テストブランチから、テスト環境で計算が行われます。バージンのテスト、修正、逆マージが実行されます。テストされたバージョンはリリースブランチに送信され、そこから本番環境に公開されます。プロダクションにミスがある場合（残念ながらこれが発生します）、プロダクションブランチから緊急モードで修正し、再びDEVブランチに保持します。

哲学では、GITは少し異なります。GITで作業する場合、マスターや開発者にコミットすることは慣習的ではないためです。代わりに、機能ブランドのアプローチが実践されています。 gitのワークフローについては、 habrahabr.ru / post / 60030をご覧ください。一般に、提案されているすべてのVCS構造には1つの目標があります。開発ブランチが安定していない状況を回避することです。構造を選択するときは、「1日だけ生産を続けて、すべてを壊すことはできませんか？答えが「はい」の場合、構造は適切です。

実稼働エラーを見逃さないために、テスト環境をできるだけターゲットに近づける必要があります。通常、主な困難は、サードパーティのWebサービスまたは他のコンポーネントと実際の金融取引に関連する操作への依存です。

構成

環境をどのように同一にしようとしても、構成ファイルは異なります。テストアカウントと実際のアカウント、トークン、ID、外部Webサービスなどです。 .NETは、構成を最新の状態に保つための優れたツール、構成変換を提供します。何らかの理由で、すぐに使用できるように、Webアプリケーションにのみ含まれています。幸いなことに、変換は他のアプリケーションに追加するのに十分簡単です。

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" /> <Target Name="AfterCompile" Condition="Exists('App.$(Configuration).config')"> <!--Generate transformed app config in the intermediate directory--> <TransformXml Source="App.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="App.$(Configuration).config" /> <!--Force build process to use the transformed configuration file from now on.--> <ItemGroup> <AppConfigWithTargetPath Remove="App.config" /> <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config"> <TargetPath>$(TargetFileName).config</TargetPath> </AppConfigWithTargetPath> </ItemGroup> </Target>

初心者の開発者は、ローカルマシンでWeb.configの変換をデバッグするときにしばしば混乱に陥ります。App.configとは異なり、bin。フォルダーではなくアプリケーションレベルで保存されるため、ローカルアセンブリ中に変換は行われません。変換は、プロジェクトを公開するときに適用されます。この制限を本当に回避する必要がある場合は、Web.template.configファイルを作成し、PostBuildアプリケーションに変換を追加できます。プロジェクトから変換タスクを削除することを忘れないでください。削除しないと、変換が2回適用されます。

アプリケーションで他のテクノロジーが使用されている場合、参照設定を変更するための一般設定と追加の設定ファイルを含む1つのメイン設定ファイルを保持することをお勧めします。これにより、同じ設定のコピーアンドペーストから保存されます。

プロジェクトにないファイルを計算に追加する

  <PropertyGroup> <CopyAllFilesToSingleFolderForPackageDependsOn> CustomCollectFiles; $(CopyAllFilesToSingleFolderForPackageDependsOn); </CopyAllFilesToSingleFolderForPackageDependsOn> </PropertyGroup> <Target Name="CustomCollectFiles"> <!-- Copy JavaScript files --> <ItemGroup> <CompressedScripts Include="Sources\**\*.js" /> <FilesForPackagingFromProject Include="%(CompressedScripts.Identity)"> <DestinationRelativePath>Sources\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath> </FilesForPackagingFromProject> </ItemGroup> <!-- Copy stylesheets --> <ItemGroup> <CompressedScripts Include="Sources\**\*.css" /> <FilesForPackagingFromProject Include="%(CompressedScripts.Identity)"> <DestinationRelativePath>Sources\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath> </FilesForPackagingFromProject> </ItemGroup> </Target>

製品のバージョン管理

.NETは、アセンブリのバージョン管理に2つの属性を提供

[アセンブリ：AssemblyVersion（ "1.0.0.0"）]

[アセンブリ：AssemblyFileVersion（ "1.0.0.0"）]

最初の2桁は、メジャーバージョン番号とマイナーバージョン番号です。これらの数値は、機能変更の増分を解釈します。 3桁目は、いわゆるアセンブリ番号です。毎日、バージョンの開発中に、このバージョンが増加します。そして最後の番号はリビジョン番号です。この数は、日中にビルドサーバーでバージョンをビルドするたびに増加します。 .NETバージョン管理ポリシーの詳細は、C＃を介したRichterのCLRで説明されています。

自動バージョン管理はさまざまな方法で構成できます。このトピックの詳細については、 stackoverflow.com / questions / 1126880 / how-can-i-auto-increment-the-c-sharp-assembly-version-via-our-ci-platform-hudsoで説明します。

主なアプローチ

バージョン1.0のバージョンを使用する*。*（ビルドサーバーではうまく機能しません）
単一のファイルSharedAssemblyInfoを使用して、この場所からすべてのアセンブリのバージョンを管理します（バージョン番号を持つ1つのファイルが作成され、「リンクとして」がすべてのプロジェクトに追加されます）
AssemblyInfoファイルの代わりにmsbuildを使用する
TFSの場合、WWF-Activityを使用できます

私の意見では、msbuildを使用し、CIサーバーを使用して値を記録するのが最も便利です。

 <Major>1</Major> <Minor>0</Minor> <Build>$(BUILD_NUMBER)</Build>

最新のCIソリューションはすべて、ビルド時にこのような変数を提供します。このアプローチを機能させるには、 msbuildtasks.tigris.orgからmsbuildタスクのインポートを追加し、プロジェクトの最後に追加する必要があります。

 <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" /> <Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')"> <Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" /> <AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " /> </Target>

データベースのバージョン管理

データベースを変更する必要のない単一のプロジェクトを知りません。 .NETは次のソリューションを提供します。

SSDTプロジェクトmsdn.microsoft.com/en-us/data/tools.aspx

長所：データベースを作成および編集するプロセスは、Management Studioで行う方法に似ています。

短所：移行スクリプトを書くのが難しい。なぜなら増分変更はプロジェクト自体によって構築され、データのセキュリティは展開前および展開後のスクリプトによって保証されます。データベース内のフィールドの有無に依存するか、移行エンジンに既に実装されているスキーマバージョンテーブルを「作成」する必要があります。

ECM7移行コードcode.google.com/p/ecm7migrator

オープンソースの移行エンジン。このプロジェクトは、 dima117 habrayuzerによってサポートされています。

長所：さまざまなDBMSがサポートされています。何かがあなたに合わない場合、コードはオープンです。 migratorはサポートされており、新しい機能で大きくなりすぎています。そして、おそらく最も重要なことは、1つのデータベースで複数の移行キーをサポートすることです。これは、アプリケーションがモジュール式であり、何らかの形でプラグインをサポートしている場合に非常に役立ちます。各プラグインは、独自の移行を実行し、同時に1つのデータベースを使用できます。

短所： Entity Framework Migrationsの利点はありません。

Entity Framework Migrations blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

長所：すぐに使用でき、Dbコンテキストで自動的に移行を作成し、Visual Studioコンソールからコマンドを理解し、移行は標準のVisual Studioから発行を使用して発行されます。

短所： Entity Frameworkに依存します。

3つのソリューションすべてを試すことができました。 EFを使用する場合、選択は間違いなくEF移行です。.NHibernateの場合はECM7 Migratorを使用できます。 SSDTプロジェクトは、ウィザードとウィンドウが好きな人に適しています。

アプリケーションの公開を自動化する

2012年には、Webプロジェクトのスタジオ公開システムが大幅に改善されました。これは主に出版物プロファイルに関係します。 Azureでアプリケーションを公開する場合、プロファイルはポータルから簡単にダウンロードできます。それ以外の場合は、作成する必要があります。

スクリーンショットに見られるように、WebDeployの最新バージョンでは、1つのチェックマークだけでEF移行を実行できます。さらに、スタジオからのパブリケーションは、変換を使用せずに接続文字列を置き換えることができます。

変換と公開の詳細は、Troy Huntの記事（ www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html）に記載されています。ここで、彼のガイドラインの5番目のステップ、つまりビルドサーバーを使用した自動公開に注目しています： www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html 私はTeamCityの大ファンなので、この特定のCIを見てみましょう。

Windowsサービスの公開を自動化する

Windowsサービスを自動的に作成する最も簡単な方法は、scコマンドを使用することです。

 sc [<ServerName>] create|stop|start <ServiceName> binpath= <BinPath> start= demand

唯一の微妙な点は、バイナリを<BinPath>に配信する方法です。これはさまざまな方法で行うことができます。FTP経由でアップロードする、PowerShellを使用する、サーバーの共有フォルダーでxcopy / robocopyまたはrsyncを使用する。選択は、ネットワーク環境とセキュリティ要件によって異なります。

Teamcity

上記のツールを使用すると、時間を節約できます。ビルドサーバーをインストールしてみましょう。 TeamCity： www.jetbrains.com/teamcityをダウンロードしてインストーラーを実行し、どこでも[OK]をクリックします。

TeamCityの2つの主要な概念は、「プロジェクト」と「ビルド」です。「プロジェクト」はソリューションに対応し、ビルドはプロジェクトの意味のある一連のアクション（アセンブリ、テストの実行、サーバーへのアップロード、バックアップの作成など）を指します。

自動レイアウト

最初のステップは、Visual Studioがインストールされていないトピックの新しいバージョンをアップロードする機会を与えることです。

主なアイデアは、追加のパラメーターを使用してmsbuildステップを実行し、新しいビルド定義を作成して、最初のMsbuildステップを選択することです。コマンドラインパラメータで渡す必要があります：

 /P:Configuration=%env.Configuration% /P:DeployOnBuild=True /P:DeployTarget=MSDeployPublish /P:MsDeployServiceUrl=https://%env.TargetServer%/MsDeploy.axd /P:AllowUntrustedCertificate=True /P:MSDeployPublishMethod=WMSvc /P:CreatePackageOnPublish=True /P:UserName=AutoDeploy\Administrator /P:Password=Passw0rd

これらのオプションは、公開する場所を示します。

移行を公開するには、追加のコマンドラインステップが必要です。

 SET AssemblyName=MyMvc4App SET StartUpDirectory=MyMvc4App\bin\ SET ConnectionString=Server=tcp:XXXX.database.windows.net,1433;Database=XXXX;User ID=XXXX;Password=XXXX;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;MultipleActiveResultSets=True SET ConnectionStringProvider=System.Data.SqlClient SET ConfigFilePath=%CD%\MyMvc4App\web.config SET MigrateExe=packages\EntityFramework.5.0.0\tools\migrate.exe %MigrateExe% %AssemblyName%.dll /startUpDirectory:%StartUpDirectory% /startUpConfigurationFile:"%ConfigFilePath%" /connectionProviderName:"%ConnectionStringProvider%" /connectionString:"%ConnectionString%" /verbose

ビルドを保存します。これで、誰でもVCSから最新バージョンを投稿できます。営業日の開始前に毎日、デベロッパースタンドで公開することをお勧めします。したがって、統合の問題をできるだけ早くキャッチできます。

ローリングビルド

別の良い習慣は、トリガーを構成してビルドをビルドすることです。これにより、多くの開発者が同時にプロジェクトに取り組んでいる場合、レポまたはタイマー（たとえば10分ごと）が変更されるたびにソリューションのビルドが開始されます。通知はこのビルドに接続する必要があります。 TeamCityは、VisualStudioおよびTray-applicationのプラグインを使用して、メール、jabberによる通知をサポートしています。味わうオプションを選択してください。トレイ内のアプリケーションが好きです。ビルドが壊れている場合は、早急に修正する必要があります。

ビルドを壊さない方法

どのような方法を導入しても、開発者が収集さえされていないコードをVCSに提供しないことを100％保証する方法はありません。この問題は、管理手段の助けを借りて解決する必要があります。変更後にビルドがアセンブルされたことを確認せずに作業を中断しないでください。私が働いていたある会社では、壊れたビルドの問題は、「ビルドを壊した-ケーキを持ってきて」というルールによって頻繁に解決されました。最初に、彼らは毎日ケーキを食べて、それから彼らは止まりました。

テストを自動的に実行する

このステップは、ユニットテストと統合テストと受け入れテストに分けられます。単体テストはどの環境でも機能するため、これは重要です。すべての外部依存関係は偽物に置き換えられます。

単体テストの実行

ここではすべてが簡単です。ビルドステップ「Nunit」または「MsTest」を選択し、パターン**。Test * .dllを入力します。テストプロジェクトの名前で.Testsパターンを使用する場合、TeamCityが残りを行います。

統合および受け入れテストを実行する

これらのテストは多くの要因に依存する可能性があり、それらの起動にはローリングバックアップまたは初期化スクリプトが含まれる場合があります。このようなテストの開始時に追加のレポートを作成することもできます。プロジェクトに計算を散らかさないで、それらのための特別なビルドを作成する方が良いです。 TeamCityでは、一連のビルドを作成できます。受け入れ/統合テストを使用したビルドのビルドトリガーでは、計算を含むビルドが正常に完了したときに機能するトリガーを追加できます。受け入れテストを実行するためのそのようなビルドの作成：トピックで説明したhabrahabr.ru/post/182032

バックアップ

計算中にバックアップを作成することも自動化できます。ファイルシステムのバックアップについては、個人的にはnnbackupよりも良いものは見つかりませんでした： www.nncron.ru/index_ru.shtml

 nnbackup -n 10 verz -i <Src> -o <Destination> -s -e –v

このコマンドは、zip内にソースフォルダーを作成し、アーカイブを宛先にコピーします。ターゲットマシンにnnbackupをインストールするか、ビルドサーバーから呼び出します。設定、ビルドサーバーの場所、ネットワークオーバーヘッド、セキュリティに関する質問です。

T-SQLを使用してSQLサーバーをバックアップできます

 BACKUP DATABASE AdventureWorks2012 TO DISK='X:\SQLServerBackups\AdventureWorks1.bak', DISK='Y:\SQLServerBackups\AdventureWorks2.bak', DISK='Z:\SQLServerBackups\AdventureWorks3.bak' WITH FORMAT, MEDIANAME = 'AdventureWorksStripedSet0', MEDIADESCRIPTION = 'Striped media set for AdventureWorks2012 database; GO RESTORE DATABASE AdventureWorks FROM DISK='$(Backup)'

つまり自動バックアップを行うには、別のコマンドラインステップを追加する必要があります。または、同じコミュニティパッケージからmsbuildタスクを使用して、nnbackupにmsbuildタスクを記述できます。

さらに進んで、受け入れテストが失敗した場合にバックアップからの自動ロールバックを開始するトリガーを設定できます。その後、一連のビルドがあります。レイアウト»受け入れテスト»バックアップからのロールバック。

プロジェクト管理システムおよびバグトラッカーとの統合

ここまでは、すでに多くの便利なことを行ってきました。不快な機能が1つ残っています。ビルドサーバーは、まだ開発プロセスに接続されていません。彼は現在の開発イテレーションのタスクについて何も知りません。

TeamCityは、YouTrack、Jira、Bugzillaとの統合をサポートしています。統合は、文字通り2クリックで実行されます。その後、コミットへのコメントでタスク番号を示すと、ビルド情報に対応するタスクへのリンクが表示されます。

YouTrackは逆統合をサポートしています。主な利点：YouTrackは、バグまたは機能が閉じられたビルドの番号を自動的に示します。

アーティファクトの構築

アプリケーションがボックス化されている場合は、おそらくインストーラーを作成するか、クライアントに出荷するパッケージをデプロイする必要があります。インストーラーの作成は別のトピックです。このトピックのフレームワーク内では考慮しません。箱入り製品の場合、インストーラーまたはパブリケーションパッケージがリリースの最も重要な部分であることが重要です。このために、ビルドアーティファクトが発明されました。

アーティファクトは、ビルドの重要な結果であるファイルです。インストーラーを使用したビルドの場合、ビルドアーティファクトのマスクとしてmy-installer.exeまたはmy-package.zipを指定できます。TeamCityはそれらを対応するタブに表示します。

これは、課題トラッカーとの統合が役立つ場所です。テスターまたはマネージャーは、閉じられたタスクを確認し、ビルドのリンクをたどり、ビルドアーティファクトから修正されたバージョンを選択できます。

結論として、開発プロセスはチームごとに純粋に個別であると付け加えます。これらのプラクティスが基本です。ツールキットのさらなる開発は、製品の開発とともに行われる必要があります。私たちは、他の人々の生活を改善するためのソフトウェアを開発しています。私たちが仕事をしやすくするために、ソフトウェアを使用するのが賢明です。

最小の継続的インテグレーション

プロジェクトを手動で公開していますか？それから私たちはあなたに行きます

VCSを使用する

構成

プロジェクトにないファイルを計算に追加する

製品のバージョン管理

主なアプローチ

データベースのバージョン管理

SSDTプロジェクトmsdn.microsoft.com/en-us/data/tools.aspx

ECM7移行コードcode.google.com/p/ecm7migrator

Entity Framework Migrations blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

アプリケーションの公開を自動化する

Windowsサービスの公開を自動化する

Teamcity

自動レイアウト

ローリングビルド

ビルドを壊さない方法

テストを自動的に実行する

単体テストの実行

統合および受け入れテストを実行する

バックアップ

プロジェクト管理システムおよびバグトラッカーとの統合

アーティファクトの構築

More articles:

最小の継続的インテグレーション

プロジェクトを手動で公開していますか？ それから私たちはあなたに行きます

VCSを使用する

構成

プロジェクトにないファイルを計算に追加する

製品のバージョン管理

主なアプローチ

データベースのバージョン管理

SSDTプロジェクトmsdn.microsoft.com/en-us/data/tools.aspx

ECM7移行コードcode.google.com/p/ecm7migrator

Entity Framework Migrations blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

アプリケーションの公開を自動化する

Windowsサービスの公開を自動化する

Teamcity

自動レイアウト

ローリングビルド

ビルドを壊さない方法

テストを自動的に実行する

単体テストの実行

統合および受け入れテストを実行する

バックアップ

プロジェクト管理システムおよびバグトラッカーとの統合

アーティファクトの構築

More articles:

プロジェクトを手動で公開していますか？それから私たちはあなたに行きます