POC – TeamCity

Continuous integration and continuous deployment are practics increasingly used. Continuous integration is the practice of continuously and automatically test all the changes in the code and merge their changes to the main branch using several tools like TeamCity or Jenkins.
This practice has shown several advantages:
Reduced integration risks, with smaller merges we are avoiding that our code collides with the code from our coworkers.
Higher code quality, we will have more tests and will have more time to focus on our code.
With the version control, we can easily find and fix a branch with a bug. It’s comfortable with small branches.
The work for the testers will be more comfortable with different versions and branches can quickly isolate the bugs.
The deployment will be faster, and developers will trust more in their code.

To do this POC, that explores TeamCity as a tool to continuous integration I configured the process to a small project name ‘CityInfo’.

First things first:
Continuous integration and continuous deployment are practics increasingly used. Continuous integration is the practice of continuously and automatically test all the changes in the code and merge their changes to the main branch using several tools like TeamCity or Jenkins.
This practice has shown several advantages:
Reduced integration risks, with smaller merges we are avoiding that our code collides with the code from our coworkers.
Higher code quality, we will have more tests and will have more time to focus on our code.
With the version control, we can easily find and fix a branch with a bug. It’s comfortable with small branches.
The work for the testers will be more comfortable with different versions and branches can quickly isolate the bugs.
The deployment will be faster, and developers will trust more in their code.

To do this POC, that explores TeamCity as a tool to continuous integration I configured the process to a small project name ‘CityInfo’.

First things first:
Build Agent. Build agents are responsible for build and test the project. To configure a build agent is through the TeamCity Server. A build agent uses the software and hardware of the machine that it is installed on.

TeamCity Server. This service is responsible for the manager the builds, agents, users, and reports.

Build Queue. It is a list of trigged builds waiting for a compatible agent. The team city server manages this builds.

Build Artifacts. Information provided by the Build, for example, log files, zip archives, NuGet package.

Project. A project represents one software application/project. One project can have multiple build configurations.

Build configuration. Settings used to build an application. In the build configuration, we have to create build steps, set triggers, and a version control system for example.

Build step. Build configuration consists typically of various build steps. Each build step performs a specific part of the build process. For instance, in one build step, you can compile the source code and in the other run tests.

Build trigger. It is the rule that establishes when the build should be started. The build can be programmed to run with new commits, at specific times of the day.

The process to install TeamCity is straightforward. Just do the download for the JetBrains TeamCity page and follow all the steps.

  1. Run the executable:
  2. Select the components to install, Build agent and server.
  3. Confirme the configurations:
  4. Specify the user to run the server.
  5. Specify the user to run the agent:
  6. Finish the installation.
  7. And that’s it. We have our TeamCity Server running on http://localhost:9191/. The instruction page to start the TeamCity configuration:
  8. In the second page, we should choose a database. In the production environment we should have a private database but in this case, I will choose the default internal database.
  9. Accept the terms and conditions:
  10. Create the admin user:
  11. We already have access to the TeamCity configurations but don’t have an agent. Accessing the agents’ page we can verify that the agent is unauthorized.
  12. We just have to authorize the agent and it will be ready to start running builds:
  13. Now we can create our first project. To create a new project I used a small core .net project name CityInfo. Chose to create a new project. 
  14. For now, I will define my source code from a repository URL.
  15. I have to select the project name and the build configuration name.
  16. The TeamCity server will suggest various steps configurations that match with my kind of project. You can choose or discard however you want. I will choose all to try.
  17. To start I will just enable the build step. 
  18. It doesn’t need any alteration in the build step configurations. Just run a new build to test. 
  19. Success, we have our first build green.
  20. Next step and very important is to run unit tests. To do this I just enabled the tests step.
  21. And without any alteration, trigged a new build and it’s green again. But at this time I have more information about the tests. I can use the build log ant the tests report seeing how our build proceeded and our tests more detailed. If I wanna see the code coverage I need to alter this step configuration and alter the property Code Coverage to JetBrains dot Cover. It will work just on windows machines and produce a report wire we can see the code coverage and analyze where the tests are not covering our code. 
  22. The next step to implement is the NuGet restore. To have this I added a new step with the following configurations:
  23. At this point I cannot run any build because I have an error:
  24. The problem is that I don’t have the NuGet installed in my agent. We can install new tools in the administration configurations, under the tab Tools. 
  25. At this point, we are ready to add jest tests to our build configurations. First, we have to install node and npm in the agent machine. Then we have to create a new step builder runner “Command Line”.  We need to specify the folder where it will run and  the following custom script:
    npm install

    npm test

    If we retrigger the build we will see that it’s green. Success. Analyzing the build log we can see the test result.

  26. At this point, we have our jest test running but we don’t have a fast feedback in the first view of our build. To have this we need to install the package “jest-teamcity-reporter” in our project and alter package.json to have the following configuration:
    "jest": {
     "testResultsProcessor": "jest-teamcity-reporter"
    }

    Now in addition to the nunit unit tests, we already have the jest tests too.

Plan to implement continuous deployment and run integration tests with TeamCity

Visual Studio:

  1. Add a new Configuration Manager using visual studio. Name this configuration Deploy-dev and copy it from Debug settings.
  2. Clicking on web.config file Add Config Transforms for our new configuration settings. Populate the new file with parameters needed in the server.
  3. On project configurations, Tab Package/Publish Web define the following parameters:
    Configuration: Deploy-Dev
    IIS Web Site: Name site on IIS.
  4. You can test these configurations using Web.deploy.cmd

TeamCity:

  1. Create a new Build Configuration and add two environment variables to the project.
    1. Configuration – Deploy-Dev, basically it’s the configuration name that you want to use,
    2. TargetServer- the remote server where you wanna do the deploy.
  2. Add the first step builder MSBuild, select the build file path to the .csproj file and on Comand line parameters run the command need to do the publish, For instance:
    /P:Configuration=%env.Configuration%
    /P:DeployTarget=MSDeployPublish
    /P:MsDeployServiceUrl=https://%env.TargetServer%/MsDeploy.axd
    /P:DeployOnBuild=True
    /P:AllowUntrustedCertificate=True
    /P:MSDeployPublishMethod=WMSvc
    /P:CreatePackageOnPublish=True
    /P:UserName=AutoDeploy\Administrator
    /P:Password=Passw0rd

    You can see that we are using the environment variables here.

  3. In the dependencies tab in our build configuration, we can define this build the order for our build configurations. Per instance, this build configuration should run just after the tests build and just if the tests build had success.

To run the integration test:

Create a new build configuration just to build tests

If the integration tests pass create new build configuration to all the servers and connect everything like dependencies.

SonarQube integration.

SonarQube is a powerful tool capable to create helpful reports about the health of our projects. To have SonarQube working with our projects we need:

  1. Download SonarQube server from this link.
  2. Select your os version and run the file StartSonar.bat. In my case is it in the path “sonarqube-7.3\bin\windows-x86-64”. It should be running in the port 9000. You can access with the link localhost:9000.
  3. Download the plugin SonarQube for MSBuild. Use this link.
  4. Copy the plugin to the SonarQube folder plugins. It should be in the path “\sonarqube-7.3\extensions\plugins.”.
  5. Add a new “command line” step configuration with the following command:
    SonarScanner.MSBuild.exe begin /k:"project-key"
    MSBuild.exe /t:Rebuild
    SonarScanner.MSBuild.exe end

    Run a new build, now you should have new reports on you SonarQube Server.

Conclusion:

References:

https://www.troyhunt.com/you-deploying-it-wrong-teamcity_26/

https://confluence.jetbrains.com/display/TCD18/Concepts