Fully scripted builds and con2nuous integra2on have become more mainstream in the past years. In this talk I want to share some of the great ideas and best prac2ces for builds I’ve seen on projects that take con2nuous integra2on a step further. I will examine build pipelines, fully automated acceptance test suites, informa2on radiators, virtualised test environments, and so@ware quality reports. In addi2on I will discuss a few do’s and dont’s that can make the difference between a good build and a great build.  

1 

You will build o@en and it needs to be reliable Only two steps allowed: 1) check out 2) go deploy no other dependencies, say “NO” to ../ unfortunately... the Microso@ world, MVC installer how far to go? you *can* check in eclipse, or use a virtual image test‐driven setup 

2 

Recording is easy But needs tuning (c.f. “waitForElementPresent” addi2ons) Not scalable, copy to programming environment and add abstrac2ons 

3 

4 

ScrewUnit: Fast and easy to run Slightly tricky to make part of the build (we use Selenium here...) 

5 

Integra2on le@ at end... it’s hard to es2mate... even harder than coding Agile “solved” the es2ma2on of coding... if we developed all the stories in isola2on we s2ll have the nasty integra2on problem In the words of... “If it’s painful do it more o@en” Now the integra2on phase disappears... neat trick, eh? So, what do we need to make this happen? (next slides) 

6 

7 

1 – Check out from source control 2 – Make changes 3 – Run build 4 – Update from source control 5 – Re‐run build 6 – Check in to source control 

8 

The simple scenario: sequen2al change 

9 

Don’t check out a broken build! Never, ever leave a@er checking in How do you know it’s broken? 

10 

The web page has other uses... Status needs to be ambient – Twiher? 

11 

More visible Give the abstract build a face, care for your build! 

12 

Don’t check out while building... What should the radiator show? 

13 

Depending on who uses the radiator. If it’s for management or informa2on purposes “building” might not mean much... 

14 

you do the maths... build light shows “building” more than 50% of the 2me 

15 

Defeated by the process, concurrency Length of build does maher 

16 

Monitor this Go futher, show the length of the build stages 

17 

18 

19 

20 

21 

22 

never rebuild anything externalise configura2on ear surgery... haha 

23 

Quicker builds all round What is part of the “pre‐commit” build? Radiator for slow build should not show “building” Mind you when the slow build breaks... 

24 

some transi2ons will be manual don’t auto‐redeploy into tes2ng environment; it will confuse testers 

25 

compa2bility tes2ng speed... how much can you run in parallel? selenium/websdriver tests o@en only bound by latency, hence perfect candidates for parallelisa2on  

26 

27 

28 

29 

Code in cloud is a management “comfort” issue Customer data in the cloud (for tes2ng!) can easily be illegal... hhp://www.fakenamegenerator.com/order.php 

30 

We didn’t talk about databases... Setup, roll‐back wrappers, virtual environments  

31