Setting up your CI Environment - Revision history

Marku at 03:16, 29 April 2010

2010-04-29T03:16:00Z

← Older revision		Revision as of 03:16, 29 April 2010
Line 15:		Line 15:
	Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.		Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.

	[[Category:Running Tests ~~& Publishing Results~~]]		[[Category:Running Tests]]

Marku at 16:29, 24 September 2009

2009-09-24T16:29:12Z

← Older revision		Revision as of 16:29, 24 September 2009
Line 14:		Line 14:

	Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.		Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.

			[[Category:Running Tests & Publishing Results]]

Mikee at 17:01, 17 September 2009

2009-09-17T17:01:12Z

← Older revision		Revision as of 17:01, 17 September 2009
Line 9:		Line 9:
	* running of all STRIDE tests and results publication to Test Space		* running of all STRIDE tests and results publication to Test Space

	The first four steps above are very build/platform specific and require specific domain knowledge to implement. There are many CI servers that help make the scheduling and execution of automated build/test cycles easier to manage. In particular, we've had good success with [https://hudson.dev.java.net/ Hudson] as it's both easy to set-up and flexible in its configuration. [http://cruisecontrol.sourceforge.net/ CruiseControl] is another popular CI server and is worth serious consideration. For any particular build/test environment, there might be other tools that ~~might be~~ more appropriate - so we recommend that you spend some time investigating the existing CI tools that are available. The WikiPedia article cited above is a good place to start as well as [http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix this matrix] which compares some of the features or many popular CI servers.		The first four steps above are very build/platform specific and require specific domain knowledge to implement. There are many CI servers that help make the scheduling and execution of automated build/test cycles easier to manage. In particular, we've had good success with [https://hudson.dev.java.net/ Hudson] as it's both easy to set-up and flexible in its configuration. [http://cruisecontrol.sourceforge.net/ CruiseControl] is another popular CI server and is worth serious consideration. For any particular build/test environment, there might be other tools that are more appropriate - so we recommend that you spend some time investigating the existing CI tools that are available. The WikiPedia article cited above is a good place to start as well as [http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix this matrix] which compares some of the features or many popular CI servers.

	The final step - executing and publishing - is easily accomplished with one or more calls to the [[Stride_Runner\|stride runner]]. This tool is command -line based and should mesh well with any of the standard CI servers since most of these tools have the ability to execute command line processes.		The final step - executing and publishing - is easily accomplished with one or more calls to the [[Stride_Runner\|stride runner]]. This tool is command -line based and should mesh well with any of the standard CI servers since most of these tools have the ability to execute command line processes.

	Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.		Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.

Mikee at 17:00, 17 September 2009

2009-09-17T17:00:44Z

← Older revision		Revision as of 17:00, 17 September 2009
Line 9:		Line 9:
	* running of all STRIDE tests and results publication to Test Space		* running of all STRIDE tests and results publication to Test Space

	The first four steps above are very build/platform specific and require specific domain knowledge to implement. There are many CI servers that help make the scheduling and execution of automated build/test cycles easier to manage. In particular, we've had good success with [https://hudson.dev.java.net/ Hudson] as it's both easy to set-up and flexible in its configuration. [http://cruisecontrol.sourceforge.net/ CruiseControl is another popular CI server and is worth serious consideration. For any particular build/test environment, there might be other tools that might be more appropriate - so we recommend that you spend some time investigating the existing CI tools that are available. The WikiPedia article cited above is a good place to start as well as [http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix this matrix] which compares some of the features or many popular CI servers.		The first four steps above are very build/platform specific and require specific domain knowledge to implement. There are many CI servers that help make the scheduling and execution of automated build/test cycles easier to manage. In particular, we've had good success with [https://hudson.dev.java.net/ Hudson] as it's both easy to set-up and flexible in its configuration. [http://cruisecontrol.sourceforge.net/ CruiseControl] is another popular CI server and is worth serious consideration. For any particular build/test environment, there might be other tools that might be more appropriate - so we recommend that you spend some time investigating the existing CI tools that are available. The WikiPedia article cited above is a good place to start as well as [http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix this matrix] which compares some of the features or many popular CI servers.

	The final step - executing and publishing - is easily accomplished with one or more calls to the [[Stride_Runner\|stride runner]]. This tool is command -line based and should mesh well with any of the standard CI servers since most of these tools have the ability to execute command line processes.		The final step - executing and publishing - is easily accomplished with one or more calls to the [[Stride_Runner\|stride runner]]. This tool is command -line based and should mesh well with any of the standard CI servers since most of these tools have the ability to execute command line processes.

	Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.		Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.

Mikee at 17:00, 17 September 2009

2009-09-17T17:00:09Z

← Older revision		Revision as of 17:00, 17 September 2009
Line 1:		Line 1:
	To reap the maximum benefit from your test assets, you need to run your tests as part of a [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] environment.		To reap the maximum benefit from your test assets, you need to run your tests as part of a [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] environment.

	In this scenario, the following automated steps take place on a regular, periodic basis (typically nightly):		In this scenario, the following automated steps take place on a regular, periodic basis (typically nightly or with each new checkin):

	* ~~Automated~~ source code check out from source control system		* source code check out from source control system
	* ~~Automated~~ build of the target executable code (including STRIDE runtime and tests)		* build of the target executable code (including STRIDE runtime and tests)
	* ~~Automated~~ downloaded of executable image to the target hardware		* downloaded of executable image to the target hardware
	* ~~Automated~~ start of target code execution on the hardware		* start of target code execution on the hardware
	* ~~Automated~~ running of all STRIDE tests and results publication to Test Space		* running of all STRIDE tests and results publication to Test Space

	~~Note~~ that the ~~Test Space~~ to which the results are published ~~should~~ be configured to notify on setbacks and errors.		The first four steps above are very build/platform specific and require specific domain knowledge to implement. There are many CI servers that help make the scheduling and execution of automated build/test cycles easier to manage. In particular, we've had good success with [https://hudson.dev.java.net/ Hudson] as it's both easy to set-up and flexible in its configuration. [http://cruisecontrol.sourceforge.net/ CruiseControl is another popular CI server and is worth serious consideration. For any particular build/test environment, there might be other tools that might be more appropriate - so we recommend that you spend some time investigating the existing CI tools that are available. The WikiPedia article cited above is a good place to start as well as [http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix this matrix] which compares some of the features or many popular CI servers.

			The final step - executing and publishing - is easily accomplished with one or more calls to the [[Stride_Runner\|stride runner]]. This tool is command -line based and should mesh well with any of the standard CI servers since most of these tools have the ability to execute command line processes.

			Once these automated steps are running regularly, we recommend that the testspace to which the results are published be configured to notify on setbacks and errors. This gives the team maximum visibility of the automated tests. Any user that does not wish to be notified for the space can, of course, disable his notifications.

Timd: Created page with 'To reap the maximum benefit from your test assets, you need to run your tests as part of a [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] environmen…'

2009-09-14T16:58:23Z

Created page with 'To reap the maximum benefit from your test assets, you need to run your tests as part of a [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] environmen…'

New page

To reap the maximum benefit from your test assets, you need to run your tests as part of a [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] environment.

In this scenario, the following automated steps take place on a regular, periodic basis (typically nightly):

* Automated source code check out from source control system
* Automated build of the target executable code (including STRIDE runtime and tests)
* Automated downloaded of executable image to the target hardware
* Automated start of target code execution on the hardware
* Automated running of all STRIDE tests and results publication to Test Space

Note that the Test Space to which the results are published should be configured to notify on setbacks and errors.