{:en}Implementing Sitecore CI/CD On-premises using Azure Devops Part-1{:}{:ja}Azure DevopsPart-1を使用したオンプレミスでのSitecoreCI / CDの実装{:}

{:en}Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration can then be verified by an automated build and automated tests. This approach leads to significantly reduced integration problems, and you can detect errors quickly, and locate them more easily. The goal is to reduce the risk of seeing “integration hell” by waiting for the end of a project or a sprint to merge the work of all developers. Continuous Integration/Continuous Delivery has become a necessary practice now a days. There are numerous ways to achieve the same. One of the best approaches is DevOps. DevOps do not have a fixed definition. Stating a definition by Atlassian below- DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative siloes. Microsoft is offering DevOps services by the name of Azure DevOps. We are going to setup CI/CD over the same and will also understand to you can connect under GIT Repository with azure. So, let’s begin – After you have created Azure devops account and project, you will see similar image as below. In the left side menu you get an option of Pipelines, this is the place where we need to work on for CI/CD setup. Broadly categorizing the setup into two parts-

• Connecting Desired Repository
• Configuring CI for the same Repository

Connecting Desired Repository

1. Create a new build pipeline.
2. Connect it to your desired Git Repository. Here we are using Bitbucket.
3. Authorize your desired Repository connection.
4. Select branch for Continuous Integration.
5. Select appropriate build template. Here we are selecting ASP.NET as template.

This shows azure devops is now connected with your desired Repository.

Configuring CI for the same Repository

1. Remove Test Assemblies and Publish Symbols Path from job and add npm install, Gulp 03-Publish-All-Projects and Archive Output. Once done it will look something like the below image –
2. Use NuGet 4.4.1
3. NuGet Restore – This will restore all the required nuget for the solution.
4. Build Solution – Configure your build settings.MSBuild Arguments –    a. DeployOnBuild b. WebPublishMethod c. PackageAsSingleFile SkipInvalidConfigurations
5. Npm Install – This will add node module and let you run gulp task as we need to run gulp task to build and publish the solution.
6.  Gulp – Configure gulp to run all the task in task runner which will build and deploy the files.
   • Gulp File Path – Select your gulp file which contains the task from the Repository.
   • Gulp Task – Mention the gulp task function which will build and deploy your solution.
   I have updated gulp task to include yml files when publishing the files so that we can run unicorn directly as output folder will contain all ymls as well.
7. Archive Output – Create an archive location to keep the published solution files.
   • Root folder or file to archive – Create a folder to keep all the published files inside specific folder. I have named it as Output.
   • Archive file to create – This field contains the path for archive zip file. $(Build.ArtifactStagingDirectory) – This is a temporary location to keep your created zip file. BuildOutputQA5Jul-$(Build.BuildId).zip – This part contains file name. I have added “BuildOutputQA5Jul” as prefix and “-$(Build.BuildId)” this will add unique build id to every build for distinguishing all the output file with respect to build.
8. Publish Artifact – This method is used to deploy your output file into artifact so that you can use this file to deploy (CD) later.
9. We have configured the build step. Now let’s configure “Triggers” for CI.
10. Here will be enable continuous integration and select the branch for which you want to monitor the commits. Let’s run the build now by click on queue – So, congratulations on configuring the CI pipeline on Azure cloud along with me. For deploying CD configuration On-premises watch out this space. A continuation blog (part-2) is available here.

{:}{:ja}

継続的インテグレーションは、チームのメンバーが頻繁に作業を統合するソフトウェア開発プラクティスです。通常、各人は少なくとも毎日統合し、1日に複数の統合を行います。各統合は、自動ビルドと自動テストによって検証できます。

このアプローチにより、統合の問題が大幅に減少し、エラーをすばやく検出して、より簡単に見つけることができます。目標は、プロジェクトまたはスプリントの終了を待ってすべての開発者の作業をマージすることにより、「統合地獄」が発生するリスクを減らすことです。

継続的インテグレーション/継続的デリバリーは、今日必要な慣行になっています。
同じことを達成するための多くの方法があります。最良のアプローチの1つはDevOpsです。

DevOpsには固定定義がありません。以下にアトラシアンによる定義を述べる-

DevOpsは、ソフトウェア開発チームとITチームの間のプロセスを自動化して、ソフトウェアをより迅速かつ確実に構築、テスト、リリースできるようにする一連のプラクティスです。 DevOpsの概念は、歴史的に相対的なサイロで機能していたチーム間のコラボレーションの文化を構築することに基づいています。

Microsoftは、AzureDevOpsという名前でDevOpsサービスを提供しています。同じ上にCI / CDをセットアップし、GITリポジトリの下で紺碧で接続できることも理解します。それでは、始めましょう

Azure devopsアカウントとプロジェクトを作成すると、次のような画像が表示されます。

左側のメニューには、パイプラインのオプションがあります。これは、CI / CDセットアップのために作業する必要がある場所です。

セットアップを大きく2つの部分に分類します-

• 必要なリポジトリを接続する
• 同じリポジトリのCIを構成する

必要なリポジトリを接続する

1. 新しいビルドパイプラインを作成します。
2. 目的のGitリポジトリに接続します。 ここではBitbucketを使用しています。
3. 目的のリポジトリ接続を承認します。
4. 継続的インテグレーションのブランチを選択します。
5. 適切なビルドテンプレートを選択します。 ここでは、テンプレートとしてASP.NETを選択しています。

これは、azuredevopsが目的のリポジトリに接続されていることを示しています。

同じリポジトリのCIを構成する

1. テストアセンブリを削除し、シンボルパスをジョブから公開し、npm install、Gulp 03-Publish-All-Projects、およびアーカイブ出力を追加します。 完了すると、次の画像のようになります–
2. NuGet4.4.1を使用する
3. NuGetの復元–これにより、ソリューションに必要なすべてのnugetが復元されます。
   
4. ビルドソリューション–ビルド設定を構成します。
   
   MSBuildの引数–
   a. DeployOnBuild
   b. WebPublishMethod
   c. PackageAsSingleFile   SkipInvalidConfigurations
   
5. Npm Install –これにより、ノードモジュールが追加され、ソリューションをビルドして公開するためにgulpタスクを実行する必要があるため、gulpタスクを実行できるようになります。
   
6.  Gulp –ファイルをビルドおよびデプロイするタスクランナーですべてのタスクを実行するようにgulpを構成します。
   
   
   
   • gulpファイルパス–リポジトリからタスクを含むgulpファイルを選択します。
   • Gulpタスク–ソリューションをビルドしてデプロイするgulpタスク関数に言及します。ファイルを公開するときにymlファイルを含めるようにgulpタスクを更新しました。これにより、出力フォルダーにすべてのymlも含まれるため、ユニコーンを直接実行できます。
     
7. アーカイブ出力–公開されたソリューションファイルを保持するアーカイブの場所を作成します。
   
   
   
   • ルートフォルダまたはアーカイブするファイル–すべての公開ファイルを特定のフォルダ内に保持するフォルダを作成します。 私はそれを出力と名付けました。
   • 作成するアーカイブファイル–このフィールドには、アーカイブzipファイルのパスが含まれます。
     $(Build.ArtifactStagingDirectory) – This is a temporary location to keep your created zip file.
     BuildOutputQA5Jul-$(Build.BuildId).zip – This part contains file name. I have added “BuildOutputQA5Jul” as prefix and “-$(Build.BuildId)” this will add unique build id to every build for distinguishing all the output file with respect to build.
     
8. アーティファクトの公開–この方法は、出力ファイルをアーティファクトに展開するために使用され、後でこのファイルを使用して展開（CD）できるようにします。
   
   
   
9. ビルドステップを構成しました。 それでは、CIの「トリガー」を構成しましょう。
   
   
10. ここでは、継続的インテグレーションを有効にし、コミットを監視するブランチを選択します。
    
    
    
    キューをクリックして、今すぐビルドを実行しましょう –
    
    だから、私と一緒にAzureクラウドでCIパイプラインを構成しておめでとうございます。 CD構成を展開する場合は、オンプレミスでこのスペースに注意してください。  継続ブログ（パート2）はこちらから入手できます。

{:}