Please visit my website and subscribe to my youtube channel for more articles
Thank you for Subscribing! If you have not, Subscribe now! DevOps4Solutions helps in providing end to end solution and…
Installing the server and the default agent
The steps involved in installing TeamCity using the installation package are as follows:
- Double-click on the downloaded
setup exefile. It should bring up the installation wizard like any other setup file on Windows. Accept the license and proceed to the next step.
- The next step in the wizard is to choose the installation directory. This is where the TeamCity server (and agent) will be installed. The default directory is
C:\TeamCity. We will be calling this
<TeamCity Home directory>.
- Since the package includes both the server and the agent, the next step asks you to choose the components to be installed. You can choose to install the server, the agent, and also choose whether Windows services need to be set up for each of these components. It is recommended that you set up the server and the agent as services.
- Next, you will have to choose
<TeamCity Data directory>. This is the path where TeamCity will store its configuration, build history, users, and other data. The default for this is
Continuing on, the installation copies the files and sets up TeamCity. The next bit of configuration that needs to be set is the port for the server. The default is
covered the steps to get a basic installation of the TeamCity server and agent up and running.
Setting UP CI Server
- Django is a Python-based MVC framework to build websites and web applications
- Clone this repo “https://github.com/devops4solutions/CI_TeamCity_DjangoApp.git”
- The simple build pipeline will perform basic error checking and style checking on the code and run unit tests. If these pass, the next stage will deploy the application to a test environment, after which we will run a suite of functional tests against this deployed instance. Every check-in will have to go through all these steps to be deemed fully integrated with the mainline.
Creating a project in TeamCity
- Clicking on the Create projectlink takes us to the Create New Project page where we can create our project by providing a suitable name and an optional description for it, as can be seen in the following screenshot:
TeamCity projects can themselves contain other projects. Subprojects are useful for hierarchical display and classification of builds, and also help in easily configuring and sharing similar settings and entities across projects. One use case of subprojects is to have subprojects for each branch/release version of a code base.
The root project is a special project that is the parent of every project and is automatically created. Furthermore, it cannot be deleted or have any build configurations of its own. The main purpose of the root project is to create and maintain settings and entities (such as VCS roots) for use by all projects in the server.
Adding build configurations
Build configurations in TeamCity are a collection of tasks that make a build, along with the settings needed to describe where the build fetches the source code from, when it runs, and what artifacts it produces.
or our sample project, we will begin by adding a build configuration named
build. This build configuration will perform build activities such as checking the code for errors and running unit tests and coverage.
- The Build number format setting is used to specify the format in which the build number for each build of this build configuration is to be recorded. The exact format will depend on the type of project and/or organizational/team conventions. Some teams include plain build counters, while some teams also include the VCS
changesetinformation in the build numbers. TeamCity has the ability to specify various parameters in this field (and elsewhere) that provide such information. The default
%build.counter%parameter that is seen when creating a build configuration is one such parameter.
- We will follow semantic versioning in this book (http://semver.org/). It prescribes version numbers to be in the format
MAJOR.MINOR.PATCH. For example, the numbers may look like
2.1.567, and so on. Following this format of version numbers, we will set the Build number format as
- The Build counter setting is used to set or reset the internal build counter that TeamCity maintains for this build. We don’t have to change this now (from the default
1.) This is useful when we want to change the
MAJORversion number, say, from
2.0.x, and hence, would want to start counting builds from 1 again.
- The Artifact paths setting is used to configure the paths from which artifacts have to be uploaded for this build. TeamCity’s artifact management process is such that the generated files and folders in an agent during a build process can be marked as artifacts using this setting. These files are uploaded back to the TeamCity server and exposed via the web interface as artifacts. Any other build configuration that is dependent on this particular build configuration can fetch and use these artifacts as needed. We will come back to configuring and using artifacts in a later section and leave this setting empty for now.
- There are three Build options that can be set up as desired.
- Hanging builds detection can be enabled if we want TeamCity to detect and stop build configurations that have been running for a long time — longer than their usual runtime — and not providing any messages back to TeamCity.
- The Status widget can be enabled to make build configuration information available through various APIs. For example, Build monitors can generally access the status of a build configuration only if this setting is enabled. It is recommended to enable both these settings as they are highly useful.
- For the Limit the number of simultaneously running builds (0 — unlimited) setting, it is recommended to set a value of
1. This means that at any point in time, only one instance of this build configuration will run, which is what we require for our CI setup. Setting a positive integer nmeans that n number of instances of this build configuration will run (in n agents.) Setting it to
0will allow for a potentially unlimited number of instances (limited only by the number of available agents).
Click on VCS Settings to move to the next step of creating a build configuration.
Click on the Create and attach new VCS root button to go to the VCS creation page. The first step is to choose the VCS type. The choices include SVN, CVS, Perforce, Git, and Mercurial, among others
The Push URL setting is used to specify the URL through which we can push tags from the steps run in the build configuration. It is of use if we have to use a separate fetch URL for checking out and a separate push URL to which we can push tags. Leaving this setting empty will make use of the fetch URL for such push purposes too.
The Default branch is the branch that is to be checked and also monitored for changes. By default, it will be
refs/heads/master, that is, the
When we are building release builds out of a branch, we can use that specific branch in this setting, say
refs/heads/master/1.1.0. The Branch specification setting allows us to define additional branches/refs that need to be monitored for changes. Use tags as branches allows tags to be treated as branches in the Branch specification settings.
Username style defines how a user on TeamCity can link their username to authors of commits in the VCS. The default is Userid, which is ideal.
The Submodules settings define whether submodules must be checked while cloning/updating the repository. The default, and recommended, setting is to use Checkout, which means submodules are checked out and updated when the parent repository is cloned and updated. The other option is to ignore submodules.
Submodules are subrepositories contained within a parent Git repository. Submodules enable one repository to live within another as a subfolder but still be treated as a separate repository of its own. Consider the example of Build and Release scripts. They are common to many projects, and it is ideal to have them collocated with each project that needs them. Without duplicating such scripts, the Build and Release scripts can be maintained as a separate repository and added as submodules to the project repository that needs it.
INTRODUCING THE BUILD STEPS
Build steps are the individual sequential tasks that are performed within a build configuration.
We will choose the Command Line runner as the Runner type for the build configuration. This loads the necessary settings, which can be configured as shown in the following screenshot:
build build configuration, we will be adding two build steps. First we will perform code error, style, and complexity checking using the
flake8 tool. The command to be used is:
flake8 --exclude=migrations --ignore=E501,E225,E128,E126 .
Next, we will run the unit tests of the project, using the following command:
python manage.py test
- Download get-pip.py to a folder on your computer. Open a command prompt window and navigate to the folder containing
get-pip.py. Then run
python get-pip.py. This will install
- >python -m pip install flake8