Continuous Integration: Difference between revisions

From Bitpost wiki
No edit summary
No edit summary
Line 21: Line 21:
! BUILD TYPE
! BUILD TYPE
! RUN MODE
! RUN MODE
! INSTANCES
|-
|-
| DEV
| DEV
Line 27: Line 28:
| DEBUG, RELEASE
| DEBUG, RELEASE
| TEST, LIVE if needed
| TEST, LIVE if needed
| 1..n
|-
|-
| BARE
| BARE
Line 33: Line 35:
| NONE
| NONE
| NONE
| NONE
| 1 (bitpost)
|-
|-
| CI
| CI
Line 39: Line 42:
| RELEASE
| RELEASE
| TEST
| TEST
| 1 (bitpost)
|-
|-
| PROD
| PROD
Line 45: Line 49:
| RELEASE
| RELEASE
| LIVE
| LIVE
| 1 (bitpost)
|}
|}



Revision as of 20:23, 25 April 2016

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 INSTANCES
DEV myrepo where code is developed; ci can automatically build/run on save if desired DEBUG, RELEASE TEST, LIVE if needed 1..n
BARE myrepo.git where code is gathered and synced; no visible code NONE NONE 1 (bitpost)
CI myrepo-ci where app is automatically run and tested on any commit RELEASE TEST 1 (bitpost)
PROD myrepo-prod where live app runs available to others RELEASE LIVE 1 (bitpost)


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


Ci.png

  • 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.