TeamCity - Continuous Integration for Everybody

TeamCity - Continuous Integration for Everybody
TeamCity - Continuous Integration for Everybody
I'm writing this article in English, even my English is not that good :p. The main reason is because the audience of this article is supposed to be my colleague. I will write the article on my blog first to share with the world ^_^ and then I will copy the article to our company's forum for our internal documentation. For several article ahead, we will discuss about how can we use a "Continuous Integration" system in to support our SDLC.

If you came from Java (Programming not Island :D), maybe you are familiar with Jenkins (Jenkins-CI). Both are similar tools, written in Java, and available for Linux, Windows and Mac OS X.

But how does Continous Integration (CI) works? Here is the figure:

Continuous Integration Diagrams
Continuous Integration - A Summary of Steps
  1. Developers work to transform the requirements or stories into source code using the programming language of choice.
  2. They periodically check-in (commit) their work into a version control system (VCS)
  3. The CI server is polling the VCS for changes. It initiates the build process when it encounters a change. The build is executed using a dedicated tool for the job such as Maven, Ant or Rake etc. Depending upon the language used, the source code may need to be compiled.
  4. Static analysis is performed on the source code, to ensure compliance with coding standards and to avoid common causes of bugs.
  5. Automated unit tests are executed.
  6. The percentage of the production code exercised by the unit tests is measured using a coverage analysis tool.
  7. A binary artefact package is created. At this point we might want to assist derivation and provenence by including some additional metadata with the artefact e.g. a build timestamp, or the source code repository revision that was used to produce it.
  8. Prepare for functional testing by setting up the test fixtures. For example, create the development database schema and populate it with some data.
  9. Prepare for functional testing by provisioning a test environment and deploying the built artefact.
  10. Functional tests are executed. Post-execution, tear down any fixtures or environment established in 8 and 9.
  11. Generate reports to display the relevant metrics for the build. E.g. How many tests passed? What is the number and severity of coding standard violations?
  12. The process is continuous of course! So rinse…and repeat…. 

For the next series of this tutorial, first of all we will define the scope by using real case example. Maybe not all of the step we're implemented right now but most of them will done.

To Be Continued ...