Continuous Integration

OVERVIEW

Every project shall have one master CI node script that uses parameters to define subtasks. Running the CI script gives basic usage and documentation, so everything is predictable and easy to discover and remember and get running.

PROJECTS

• atci
• htdjci
• (TODO more...)

DETAILS

a good overview

My terminology:

• Build Type can be: DEBUG, RELEASE
• Run Mode can be: TEST, LIVE
• Environment can be:

ENVIRONMENT	FOLDER	DESCRIPTION	BUILD TYPE	RUN MODE
DEV	myrepo	where code is (mostly) written and tested app can be manually debugged without any automatic ci OR app can be automatically run and tested on any save	DEBUG, RELEASE	TEST, LIVE
BARE	myrepo.git	where code is gathered and synced; no visible code	NONE	NONE
CI	myrepo-ci	where app is automatically run and tested on any commit	RELEASE	TEST
PROD	myrepo-prod	where live app runs available to others	RELEASE	LIVE

Goals:

• on code save in DEV env: automatically build RELEASE, run TEST
• on code commit: automatically build, do any custom build steps, run any unit tests, run any end-to-end tests, and report results dynamically
• on app production release: compile artifacts, assist in automatic versioning

Tools:

• git
  • use a centralized bare repository as the origin target for all the client development environments; master will be the workhorse branch
  • git hooks, especially post-receive on the server, which triggers when a new push arrives from any client; this is the entry point for CI server builds
• Node.js
  • This allows us to write cross-platform CI scripts in a language that is fundamental to web development
  • Base Node.js provides many important cross-platform functions; it is also fundamentally asynchronous
  • Use modules and you get command-line support from any path on any platform's shell
• Windows
  • window management via AutoHotKey; see various sync ahk scripts for examples
  • Powershell; make sure to set it up to get debug output:

$global:DebugPreference = "Continue"

• Ubuntu i3
  • Use i3 scripting to manage windows placement; see various keyboard shortcuts in config file for examples

Jenkins

Installation: install on a server (TODO) For VS projects: add MSBuild plugin find the right path to msbuild.exe (eg C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe) Manage Jenkins, Configure System, add the msbuild there; USE FULL PATH, INCLUDE EXE, NO LEADING SPACES Add the Build Keeper plugin to clean up previous bad builds on rebuild Add nodes labeled according to what will be built on each Select "New Item" to add folder(s) to create a project layout Within folders, select "New Item" to create "Freestyle Projects" Configure the project: git, build+test+install script, post-build cleanup "Restrict where this project can run" with node labels poll source control ~ every 30 min: "H/30 * * * *" TODO retrieve build+test+install status, report to Jenkins

• Commit to Continuous Integration with constant automated testing
• apps should have live and test modes, made as similar as possible
• live mode: no tests, lean and mean; usually only one runs at a time in a PROD env (esp for web-driven or service-oriented apps); but you can also debug it in a DEV env
• test mode: always run automated tests on startup, but then function exactly like live mode as much as possible
• test mode: write smart tests - assert-driven development means we don't need blanket unit-testing on everything - spend time on big domain-specific tests that MATTER
• test mode: multiple simultaneous instances should be allowed, so CI can run on dev box during debugging
• live mode and test mode should be able to run simultaneously, so prod box can always be quickly tested
• dev box needs ci loop that automatically reruns release in test mode on code changes
• NOTE that during initial design/development/refactor of basic architecture, CI has less value and may actually get in the way; better to build a functioning app first.