IT:AD:Windows:Server:HowTo:Configure a new CI/CD Server

By default, a Build Server, such as IT:AD:Jenkins or IT:AD:ALM:CI:Team City will be installed to run under the local System Account.

That's not a great starting point.

So before we go on, we want to create a service account specifically for the task of running the build server.

• Use IT:AD:lusrmgr.msc to create a new User. eg: Svc-CI
• Use IT:AD:SecPol.msc to join the new account to the list of accounts that can start Services.
  • IT:AD:SecPol.msc:HowTo:Allow a user to RDP in

For tidiness sake, hide the user account from the Login screen: * IT:AD:Windows:Server:HowTo:Hide a Service Account from the Login screen

You can use IT:AD:Powershell to create a Local Service Account: * http://blogs.technet.com/b/heyscriptingguy/archive/2014/10/01/use-powershell-to-create-local-users.aspx

to run (eg: IT:AD:Jenkins) as a service.

See here: * Users

In an enterprise environment, you'll need to request Support services to create a service account with the following specs: * Password does not require change * Password does not expire

To configure the service account's ability to use SSH to contact IT:AD:BitBucket and other services, you'll have to sign as the service.

• Use IT:AD:SecPol.msc to Start/Allow Remote Access To Your Computer
• select the service account you just created (eg: Svc_CI).
• Give it RDP rights (at this point, you should be saying 'Hold on….!' but bear with me a sec.
• ie:
  • IT:AD:SecPol.msc:HowTo:Allow a user to RDP in

• RDP into the server using the service account (eg: Svc_CI).

Your build server is going to use IT:AD:Git to check out/in code from remote repositories.

Download IT:AD:Git For Windows and install it: Install

It's absolutely essential that you to prepare as directed the PATH and HOME environment variables.

Once you've downloaded IT:AD:Git, and ensured GIT is available from the PATH environment, as a Windows developer you'll probably be working from the IT:AD:Powershell CLI much more than from the IT:AD:Git Bash emulator.

Installing IT:AD:Posh-Git will help. * IT:AD:Posh-Git:HowTo:Install

Git can use both HTTPS and IT:AD:SSH to authenticate with, and it's a lot easier to get up and running with HTTPS.

Another reason to consider using HTTPS is that SSH has a dependency on Port 22 – which not all corporate firewalls will allow through.

Avoid using: * https://git-scm.com/docs/git-credential-store

and instead install the following:

• IT:AD:Git Credential Manager For Windows:HowTo:Install

Git can use both HTTPS and IT:AD:SSH to authenticate with, but the preferred and more secure way is to set up IT:AD:SSH as SSH keys are a way to identify trusted computers, without involving transmitting passwords.

Follow the Process defined here to set up SSH: * IT:AD:SSH

Configuring Git to work in a build server is hard to get right and takes time, so before you get started:

• create a couple of control test/dummy repositories, on the same Source Control server as you working projects.

  • One should be public (not requiring authentication to download): gittest_public
  • One should be private (requiring authentication to download): gittest_private

  * create a test away job definition that points to this code.

• figure it all out (the plugin configuration, etc.) with this dummy/test data instead of your production code.

Once created on Bitbucket (or wherever, you can download it):

• Go to Bitbucket and get the urls to your repo:
  • Public repo:

    • git clone https://bitbucket.org/xact/gittest_public.git
    • git clone git@bitbucket.org:xact/gittest_public.git
    • Private repo:
    • git clone https://bitbucket.org/xact/gittest_private.git
    • git clone git@bitbucket.org:xact/gittest_private.git

    * Create a local clone:

  • Start a new cmd (we're still RDP'ing as Svc_CI)
  • Clone the code from the command line using the SSH based mechanism:

C:\Users\Svc_CI\tmp>git clone git@bitbucket.org:xact/gittest_public.git
Cloning into 'gittest_public'...
warning: templates not found /share/git-core/templates
warning: You appear to have cloned an empty repository.

C:\Users\Svc_CI\tmp>git clone git@bitbucket.org:xact/gittest_private.git
Cloning into 'gittest_private'...
warning: templates not found /share/git-core/templates
warning: You appear to have cloned an empty repository.

Boring, but proves:

• Git worked
• Git and SSH worked, as it actually found the SSH certificates needed to retrieve the private repository.

For now, that's all we can do to prepare.

Some of the Jobs I use Jenkins for package the built assemblies and upload them to Nuget.org.

For the Build Server to do that, the service under which it is running will need to have its Nuget key set:

• RDP back into the
• nuget setApiKey Your-API-Key
  • eg: nuget setAPIKey 3ac5a5f6-166a-4e%p3-%pdbf-64%p%be136ffb7
• Verify the values were saved correctly by by looking in the Service account's config file: %APPDATA%\NuGet\NuGet.Config

c:\Users\Svc_CI>nuget setAPIKey ...xxx...
The API Key '...xxx...' was saved for the NuGet gallery (https://www.nuget.org) and the symbol server (http://nuget.gw.symbolsource.org/Public/NuGet).

c:\Users\Svc_CI>dir %APPDATA%\Nuget
Directory of C:\Users\Svc_CI\AppData\Roaming\Nuget
...
01/28/2014  09:18 PM               931 NuGet.Config
...
c:\Users\Svc_CI>

All that was required before you install your preferred Build server

• IT:AD:Jenkins
• Team City

Using http://localhost:8080 from the server is fine – but not satisfactory for production work. You probably have a better url to use instead (eg: 'jenkins.mysite.com'). So we need to use IIS's ARR mechanism.

• Ensure ARR is installed: http://bit.ly/vF8mcU
• Create a WebFarm
  • Call it Jenkins@8080
  • Set it's url to localhost
  • Set its port to 8080
  • Click Add.
  • It will suggest creating a Routing Rule. Accept.
• Edit the Rule.
  • The rule created is a good start – but it's collecting '' – ie. too much. * Add a condition, that {HTTP_HOST} == 'jenkins.mysite.com' * It's already redirecting to the WebFarm. * Save. * Done. Try to http://localhost:8080 first.
• Now try http://jenkins.mysite.com – Should work.

• http://blogs.technet.com/b/heyscriptingguy/archive/2014/10/01/use-powershell-to-create-local-users.aspx