Rick Martin - Continuous Integration

Owned by David Harms
Sept 26, 2013
2 min read

Why use automated builds and/or continuous integration? It's difficult to merge and integrate changes from multiple developers. Clarion makes this more difficult because APP and DCT files are binary. But the longer you wait between committing chunks of code the harder it is to manage integration. So continuous (or at least frequent) helps a lot. When a bug shows up, you're more likely to know what your code does if it gets committed close to the time you wrote it. 

Products

  • Cruise Control.NET (CC.Net)
  • TeamCity
  • Build Automator
  • Batch files

CC.Net is open source available on SourceForge. Project configuration is via XML files. Provides support for many different source control systems. 

You can trigger CC.Net in many different ways - by various time settings (once per week, every night, every day at noon except on Sunday, etc). 

CC.Net's XML files can be daunting - Rick showed the essential settings to detect changes, grab those changes from the repository (on github.com, in this case)

Rick likes SmartGit. There are also the free Tortoise products for most version control systems.

TeamCity is all web-based, for output and for configuration. Rick had the same project under TeamCity control, so it had been doing a build at the same time as CC.Net.

BuildAutomator from IceTips supports stringing commands together as a project. This isn't quite the same as CC.Net or TeamCity but you can do certain kinds of automation with it. Arnor does expect to spend more time on BA in the near future. 

Brief overview of source control systems:

  • Git - distributed
  • Mercurial (Hg) - distributed
  • SVN - traditional, centralized server

Source control clients

  • TortoiseGit/Hg/SVN is free
  • SmartGit / SmartHg is paid for ($80)

You don't have to do it all right away. Get started with source control. Start automating your processes.