Comments for JayFlowers http://jayflowers.com/WordPress Bodhisattva in Training Fri, 16 Mar 2012 15:23:03 -0500 hourly 1 http://wordpress.org/?v=3.1.3 Comment on Switching to Jenkins–SVN Revision Number as the Build Number by JayFlowers > Switching to Jenkins–Download and Install Artifact Script for Tester http://jayflowers.com/WordPress/?p=258#comment-38517 JayFlowers > Switching to Jenkins–Download and Install Artifact Script for Tester Fri, 16 Mar 2012 15:23:03 +0000 http://jayflowers.com/WordPress/?p=258#comment-38517 [...] « Switching to Jenkins–SVN Revision Number as the Build Number [...] [...] « Switching to Jenkins–SVN Revision Number as the Build Number [...]

]]> Comment on Continuous Integration Practices–Precommit Process by A Smattering of Selenium #81 « Official Selenium Blog http://jayflowers.com/WordPress/?p=232#comment-36125 A Smattering of Selenium #81 « Official Selenium Blog Mon, 12 Mar 2012 08:02:09 +0000 http://jayflowers.com/WordPress/?p=232#comment-36125 [...] What’s your team’s Precommit Process? [...] [...] What’s your team’s Precommit Process? [...]

]]> Comment on Continuous Integration Principles–Task Size Rules by Kelly Summerlin http://jayflowers.com/WordPress/?p=222#comment-26798 Kelly Summerlin Thu, 05 Jan 2012 14:56:46 +0000 http://jayflowers.com/WordPress/?p=222#comment-26798 After reviewing your diagram again, I think I need to restate my previous comments. Your diagram seems to take the point that the CI build being broken causes stress and that stress is greater with larger change sets -- which is absolutely true. Having worked with teams that are both very diligent about not breaking the build and teams that break the build about four or five times a day, I have become a proponent of separating the code that has yet to go through a green bar CI build. This means that code in the main branch has at least gotten past the CI gatekeeper. Code that breaks the CI doesn't affect every other developer on the team, only the person(s) that checked in the breaking code. This usually means pulling from one branch and pushing to another CI branch (in git terms). The CI build is then responsible for pushing green bar change sets out to the main branch. Takes a little more discipline though. After reviewing your diagram again, I think I need to restate my previous comments. Your diagram seems to take the point that the CI build being broken causes stress and that stress is greater with larger change sets — which is absolutely true.

Having worked with teams that are both very diligent about not breaking the build and teams that break the build about four or five times a day, I have become a proponent of separating the code that has yet to go through a green bar CI build. This means that code in the main branch has at least gotten past the CI gatekeeper. Code that breaks the CI doesn’t affect every other developer on the team, only the person(s) that checked in the breaking code. This usually means pulling from one branch and pushing to another CI branch (in git terms). The CI build is then responsible for pushing green bar change sets out to the main branch. Takes a little more discipline though.

]]> Comment on Continuous Integration Principles–Task Size Rules by Kelly Summerlin http://jayflowers.com/WordPress/?p=222#comment-26797 Kelly Summerlin Thu, 05 Jan 2012 14:17:08 +0000 http://jayflowers.com/WordPress/?p=222#comment-26797 The main fault I have with this diagram (and this thinking) is that there is only one build. CI is about integrating my code with other developer's code, not about getting a build out there for QA. This means you need at least two builds. One build that is truly continuous on a build server meant to validate my code and your code as well as my tests and your tests work correctly when integrated. That build should never really "available" to anyone. A QA build on the other hand should integrate only things we know build correctly and have 100% passing tests (unit, integration tests). That build should theoretically always be available. But when that build is unavailable, it can be very hard to determine why it is unavailable, especially when the CI build is all green. The main fault I have with this diagram (and this thinking) is that there is only one build. CI is about integrating my code with other developer’s code, not about getting a build out there for QA. This means you need at least two builds. One build that is truly continuous on a build server meant to validate my code and your code as well as my tests and your tests work correctly when integrated. That build should never really “available” to anyone.

A QA build on the other hand should integrate only things we know build correctly and have 100% passing tests (unit, integration tests). That build should theoretically always be available. But when that build is unavailable, it can be very hard to determine why it is unavailable, especially when the CI build is all green.

]]> Comment on Continuous Integration Principles–Task Size Rules by Loop diagram on task size | Jack's Sleazy Hacks http://jayflowers.com/WordPress/?p=222#comment-26684 Loop diagram on task size | Jack's Sleazy Hacks Tue, 03 Jan 2012 20:41:19 +0000 http://jayflowers.com/WordPress/?p=222#comment-26684 [...] http://jayflowers.com/WordPress/?p=222 [...] [...] http://jayflowers.com/WordPress/?p=222 [...]

]]> Comment on Continuous Integration Principles–Task Size Rules by A Smattering of Selenium #72 « Official Selenium Blog http://jayflowers.com/WordPress/?p=222#comment-26662 A Smattering of Selenium #72 « Official Selenium Blog Tue, 03 Jan 2012 13:00:38 +0000 http://jayflowers.com/WordPress/?p=222#comment-26662 [...] Continuous Integration Principles–Task Size Rules has a diagram that seems about right — even if I haven’t really thought about it in great depth. [...] [...] Continuous Integration Principles–Task Size Rules has a diagram that seems about right — even if I haven’t really thought about it in great depth. [...]

]]> Comment on Book: Test Driven .NET Development with FitNesse by Test Driven http://jayflowers.com/WordPress/?p=203#comment-25006 Test Driven Sat, 10 Dec 2011 08:57:59 +0000 http://jayflowers.com/WordPress/?p=203#comment-25006 This book is primarily aimed at .NET developers interested in starting with TDD and those who already practise unit testing and want to move beyond that into development driven by acceptance testing. It will also be useful to Java developers who are experienced with FitNesse, but wish to use it in a .NET environment. The .NET and Java implementations differ significantly in some ways, and this book points out all the important .NET-specific features. Java developers can also benefit from the third part of this book, where we discuss best practices for using FitNesse in a team environment and integrating FitNesse into the wider software development ecosystem, including web and database tests. You will learn when to use FitNesse, when not to use it, and when to combine it with unit testing tools. Contents Introduction Installing FitNesse Our Project Writing basic tests Writing simple test scripts Writing efficient test scripts Removing duplication Coordinating fixtures Working with collections Working in a team Testing web interfaces Testing database code Testing legacy code Using business domain objects directly Tips and tricks This book is primarily aimed at .NET developers interested in starting with TDD and those who already practise unit testing and want to move beyond that into development driven by acceptance testing. It will also be useful to Java developers who are experienced with FitNesse, but wish to use it in a .NET environment. The .NET and Java implementations differ significantly in some ways, and this book points out all the important .NET-specific features. Java developers can also benefit from the third part of this book, where we discuss best practices for using FitNesse in a team environment and integrating FitNesse into the wider software development ecosystem, including web and database tests.

You will learn when to use FitNesse, when not to use it, and when to combine it with unit testing tools.

Contents

Introduction
Installing FitNesse
Our Project
Writing basic tests
Writing simple test scripts
Writing efficient test scripts
Removing duplication
Coordinating fixtures
Working with collections
Working in a team
Testing web interfaces
Testing database code
Testing legacy code
Using business domain objects directly
Tips and tricks

]]> Comment on AsyncExec and WaitForExit: Speeding Up The Build To Do More by JayFlowers > AsyncExec and WaitForExit: Speeding Up The Build To Do More « Hornet Dear Bernard http://jayflowers.com/WordPress/?p=101#comment-10072 JayFlowers > AsyncExec and WaitForExit: Speeding Up The Build To Do More « Hornet Dear Bernard Tue, 08 Mar 2011 08:42:29 +0000 http://jayflowers.com/WordPress/?p=101#comment-10072 [...] JayFlowers > AsyncExec and WaitForExit: Speeding Up The Build To Do More: [...] [...] JayFlowers > AsyncExec and WaitForExit: Speeding Up The Build To Do More: [...]

]]> Comment on CI Factory RC1 1.0 by Treppenlift http://jayflowers.com/WordPress/?p=200#comment-10065 Treppenlift Wed, 03 Nov 2010 16:21:22 +0000 http://jayflowers.com/WordPress/?p=200#comment-10065 the site is fine. thank the site is fine. thank

]]> Comment on Demanding of Ant: 1 scriptdef by ugg australia uk http://jayflowers.com/WordPress/?p=213#comment-10024 ugg australia uk Mon, 21 Jun 2010 09:45:02 +0000 http://jayflowers.com/WordPress/?p=213#comment-10024 good job,guys. good job,guys.

]]>