Skip to content

Latest commit

 

History

History
179 lines (129 loc) · 7.82 KB

README.md

File metadata and controls

179 lines (129 loc) · 7.82 KB
Raw

<< Back to main README.md

The Build Templates allow you to quickly frame up a full build, with many bells and whistles prepackaged. Only a few properties need to be updated after importing the Build Template.

Import Build Template into VSTS Project

Click to toggle contents...

From a VSTS instance:

  1. First, you need to get the Project ID.
    1. Log in to the VSTS project from a browser.
    2. Once authenticated, visit https://<VSTS Project URL>/_apis/projects in a browser window.
    3. This will output all current projects in JSON format. Look for the project with the proper "Name", then find the corresponding "id" property, remember this.
  2. Navigate to the desired template in your local repository at ~\BuildTemplates\
    1. For IaaS/VMs builds, use sitecore.vsts.build.IaaS.json
    2. For PaaS builds, use TBD
  3. Edit this *.json file
  4. Scroll all the way to the bottom and find the "project" property.
    1. Modify the "id" property to match the GUID you found in step 1 above. (Replace "UPDATE-THIS-TO-YOUR-PROJECT-ID")
  5. Save your modified *.json file.
  6. From VSTS online, navigate to the Builds page (Page name: Build pipelines) Import Build
  7. Click "+ Import"
  8. Click "Browse..."
  9. Click "Import"
  10. When the build definition loads, it will require some attention.
    1. Process
      1. Change name: Remove "-import" from the end of the name. For example, "Base Build".
      2. Select the proper "Agent queue". This will likely be "Hosted VS2017".
    2. Get sources
      1. It should automatically select the current projects VSTS Git repo when you select this task. If not, select the proper source.
      2. Verify it is pulling from the proper branch, master by default.
  11. Click "Save & queue > Save"
    1. No folder selection is required.
    2. No comment is required.

This build template assumed you will be using TDS Classic and enable Update Packages (preferrably of Items Only) for your deployment. It also assumes that the output of the TDS project (targeted Web Project) is used as the primary artifact to promote to all environments. The TDS Classic output of the web project produces more consistent configuration transformations.

Build Process

Note the Parameters. The "Path to solution or packages.config" defaults to **\*.sln and "Artifact Name" defaults to drop. These are linked to some of the Build Tasks.

Build Parameters

Variables on Build Template

Click to toggle contents...

Build Variables

BuildPlatform

  • Default Value: Any CPU
  • This will likely not change

BuildConfiguration

  • Default Value: Release
  • This is the Solution Configuration you are targeting for VSTS builds. Release is preferred, though another may be accurate for your instance.

CullProjectFiles

  • Default Value: False
  • Dependent on: EnableGitDeltaDeploy
  • Possible Values: True or False
  • This is used with GitDeltaDeploys. It reduces the number of files included in the output to only changed files depending on GitDeltaDeploy configuration.

EnableGitDeltaDeploy

  • Default Value: False
  • Possible Values: True or False
  • To use this setting, be sure to add the GitDeltaDeploy NuGet package to all TDS projects.

LastDeploymentGitTagname

  • Default Value: "ProductionRelease"
  • Dependent on: EnableGitDeltaDeploy
  • This is the tag that GitDeltaDeploy will reference when it performs it's delta of items and files. It will only include changed items/files between the current build and the commit with this tag.

LastProductionReleaseCommitId

  • Default Value: (none)
  • Dependent on: EnableGitDeltaDeploy
  • Instead of using the LastDeploymentGitTagname, you may instead wish to target a specific commit. Note: You will need to update the MS Build arguments to use a commit id instead of a tag name.

system.debug

  • Default Value: true
  • Possible Values: true or false
  • If true, this increases the verbosity of the build log output.

TDS_Key

  • Default Value: "KEY"
  • Enter your organizations TDS Classic Key in this field to allow the build server to perform a build via TDS Classic.

TDS_OWNER

  • Default Value: "OWNER"
  • Enter your organizations TDS Classic Owner in this field to allow the build server to perform a build via TDS Classic.

Build Steps (Build Sitecore Solution)

Click to toggle contents...

Build Steps

Download GeekHive Scripts

  • Fields: No fields require attention.
  • This is an inline PowerShell script that pulls down the contents of https://github.com/GeekHive/SitecoreVSTS for use on the build. This step is critical if you wish to use these scripts further in the process: in further Build Steps or with the templated Release Task Groups. The idea is to exclude build/release scripts from your repository and pull them in as-needed during the deployment.
  • Note: It is recommended that you fork this repository and reference your fork in order to assure you have full control of your scripts.

NuGet restore **\*.sln

  • Fields: Likely that no fields require attention.
  • This pulls in all NuGet packages based on the individual packages.config files referenced by each project.

Build solution **\*.sln

  • Fields:
    • Visual Studio Version
      • Default Value: Visual Studio 2017
      • If you are building our your project on an earlier version, update to be correct.
    • MSBuild Arguments
      • Default Value: /p:OutDir=$(Build.ArtifactStagingDirectory) /p:SkipInvalidConfigurations=true /p:LastDeploymentGitTagName=$(LastDeploymentGitTagName) /p:CustomGitDeltaDeploy=$(EnableGitDeltaDeploy) /p:CullProjectFiles=$(CullProjectFiles)
      • Most of the arguments are driven by Build Variables, but you may want to modify "LastDeploymentGitTagName=$(LastDeploymentGitTagName)" if you instead choose to use "LastDeploymentGitCommitID=&(LastProductionReleaseCommitId)" instead and then update the Build Variable "LastProductionReleaseCommitId". If GitDeltaDeploy is not used, clear the LastDeployment* variables values and set "EnableGitDeltaDeploy" to "False".
  • This task builds the solution. Note, we typically rely on the output of the TDS project that points to the primary Web Project as our promoted build output.

Delete files from $(Build.ArtifactStagingDirectory)

  • Fields:
    • Contents
      • Default Value: *.dll *.pdb *.config *.xml App_Config
      • Enter the files you wish to remove from the promoted build artifact.
  • This task simply cuts down on the size of the promoted artifact. It isn't critical, but makes for a more slimmed down artifact.

Remove Files From TDS Packages

  • Fields:
    • Script Path
      • Default Value: $(Build.ArtifactStagingDirectory)\SitecoreCICD\Scripts\Build\RemoveFilesFromTDSPackage.ps1
      • Likely no changes needed
    • Arguments
      • Default Value: -pathToPackages "$(Build.ArtifactStagingDirectory)_Packages"
      • Likely no changes needed
  • Automatically, recursively seeks out *.update files and removes an files from the ~\bin directories.
  • Assumes TDS Update packages are set to "Items Only".

Publish Artifact: drop

  • Fields: Likely that no fields require attention.
  • This step promotes the artifacts to VSTS cloud for later consumption by Release Tasks, per environment.