Continuous Integration - Revision history

M at 18:39, 27 November 2016

2016-11-27T18:39:38Z

← Older revision		Revision as of 18:39, 27 November 2016
Line 7:		Line 7:
	CI helps solve these.		CI helps solve these.

	=== ~~My Terminology~~ ===		=== TERMINOLOGY ===

	* '''Build Type''' can be: DEBUG, RELEASE		* '''Build Type''' can be: DEBUG, RELEASE
	* '''Run Mode''' can be: TEST, LIVE		* '''Run Mode''' can be: TEST, LIVE

M at 18:39, 27 November 2016

2016-11-27T18:39:06Z

@@ Line 7: / Line 7: @@
 CI helps solve these.
-=== PROJECTS ===
+=== My Terminology ===
 * '''Build Type''' can be: DEBUG, RELEASE
 * '''Run Mode''' can be: TEST, LIVE
@@ Line 59: / Line 48: @@
 |}
 Goals:

M at 18:37, 27 November 2016

2016-11-27T18:37:13Z

← Older revision		Revision as of 18:37, 27 November 2016
Line 1:		Line 1:
			=== CHALLENGES ===
	Some of the difficult demons to fight with long-term development:		Some of the difficult demons to fight with long-term development:
	* The development code loop is the most important thing of all to optimize; you should always see the full results of any code change as immediately as possible		* The development code loop is the most important thing of all to optimize; you should always see the full results of any code change as immediately as possible
Line 44:		Line 45:
	\|-		\|-
	\| CI		\| CI
	\| myrepo-ci		\| myrepo (or myrepo-ci)
	\| where app is automatically run and tested on any commit		\| where app is automatically run and tested on any commit
	\| RELEASE		\| RELEASE

M at 18:36, 27 November 2016

2016-11-27T18:36:04Z

← Older revision		Revision as of 18:36, 27 November 2016
Line 1:		Line 1:
	~~=== OVERVIEW ===~~		Some of the difficult demons to fight with long-term development:
	~~There are~~ difficult demons to fight with long-term development:		* The development code loop is the most important thing of all to optimize; you should always see the full results of any code change as immediately as possible
			* Things break; you have to know ASAP to keep projects healthy, so you must regression test constantly
	* Inevitably you must set up for development on a new box that doesn't have any previous configuration		* Inevitably you must set up for development on a new box that doesn't have any previous configuration
	* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor		* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor
	CI helps solve these.		CI helps solve these.

			=== PROJECTS ===
	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.		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		* atci
	* htdjci		* htdjci

M at 17:29, 27 November 2016

2016-11-27T17:29:11Z

← Older revision		Revision as of 17:29, 27 November 2016
Line 63:		Line 63:
	* 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 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		* on app production release: compile artifacts, assist in automatic versioning
			* quickly configure new environments

	Tools:		Tools:

M at 17:26, 27 November 2016

2016-11-27T17:26:21Z

← Older revision		Revision as of 17:26, 27 November 2016
Line 1:		Line 1:
	=== OVERVIEW ===		=== OVERVIEW ===
	There are difficult demons to fight with long-term development:		There are difficult demons to fight with long-term development:
	* Regression testing should be continuous so breakage is discovered ASAP
	* Inevitably you must set up for development on a new box that doesn't have any previous configuration		* Inevitably you must set up for development on a new box that doesn't have any previous configuration
	* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor		* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor
Line 64:		Line 63:
	* 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 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		* on app production release: compile artifacts, assist in automatic versioning
	* configure new dev environments in one step

	Tools:		Tools:

M at 17:22, 27 November 2016

2016-11-27T17:22:38Z

← Older revision		Revision as of 17:22, 27 November 2016
Line 1:		Line 1:
	=== OVERVIEW ===		=== OVERVIEW ===
	There are difficult demons to fight with long-term development:		There are difficult demons to fight with long-term development:
			* Regression testing should be continuous so breakage is discovered ASAP
	* Inevitably you must set up for development on a new box that doesn't have any previous configuration		* Inevitably you must set up for development on a new box that doesn't have any previous configuration
	* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor		* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor
Line 63:		Line 64:
	* 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 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		* on app production release: compile artifacts, assist in automatic versioning
			* configure new dev environments in one step

	Tools:		Tools:

M at 17:14, 27 November 2016

2016-11-27T17:14:57Z

← Older revision		Revision as of 17:14, 27 November 2016
Line 10:		Line 10:
	* atci		* atci
	* htdjci		* htdjci
			* nu (causam "nop-util")
	* (TODO more...)		* (TODO more...)

M at 17:13, 27 November 2016

2016-11-27T17:13:35Z

← Older revision		Revision as of 17:13, 27 November 2016
Line 1:		Line 1:
	=== OVERVIEW ===		=== OVERVIEW ===
			There are difficult demons to fight with long-term development:
			* Inevitably you must set up for development on a new box that doesn't have any previous configuration
			* It's very difficult to remember the basics after returning to a project after a long hiatus or deep multi-day refactor
			CI helps solve these.

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

M at 14:12, 5 May 2016

2016-05-05T14:12:41Z

← Older revision		Revision as of 14:12, 5 May 2016
Line 77:		Line 77:
	\| Installation:		\| Installation:
	* install on a server (TODO)		* install on a server (TODO)
			* Install a windows slave if
			** Set up a windows machine on the (V)LAN that can be reached by jenkins server
			** Install Java on it, as well as build tools (node.js, npm, visual studio...)
			** Add a build slave in jenkins, use the Java run-slave-agent button to run the agent on it; use the menu to install as a windows service
			** To run node modules you have installed under the logged-in user, you should stop the service, change it to run as that user, and restart the service
	* For VS projects:		* For VS projects:
	** add MSBuild plugin		** add MSBuild plugin