Paul Julius > Blog

CITCON Turin Registrations Open!

September 3rd, 2013

Open Spaces Board

Open Space conferences naturally cater their agenda to exactly the people in attendance.

We just finished with CITCON Boston, and now we are headed to Italy for CITCON Turin! September 27 & 28 at the TalentGarden Torino.

Marco Abis volunteered to help find a great venue in Turin. The entire organizing committee and I are excited to bring CITCON to Italy for the European leg of the conference this year.

CITCON Turin will round out the 8th year of CITCON’s around the world as the 21st instance of the conference. A lot has changed in 8 years. A few highlights come to mind:

  1. Fewer discussions about “What is CI”
  2. More discussion about “What is CD”
  3. I can remember as far back as 2002, colleagues at ThoughtWorks were discussing how to take CruiseControl and Continuous Integration to the next level. They had already played out the limits of traditional CI. They were looking for ways to take the same principles all the way down the pipe to production. The concept had a few names over the years – CI ++, Enterprise Continuous Integration, Continuous Deployment. Personally, I am grateful to Jez Humble and Dave Farley for getting their book published! Finally we have a name for it – Continuous Delivery.

  4. More discussion about DevOps
  5. I think Patrick Debois coined the term when he created DevOps Days after attending CITCON Brussels. A name can say a lot, as we see with Continuous Delivery. People are still trying to figure it all out, as indicated by Jez’s post on the oxymoronic phrase “A DevOps Team”. CITCON provides us professionals with another venue to hash it all out.

  6. More in-depth Automated Testing discussion
  7. Testers (QA Engineers, etc) are stepping up in droves to integrate their work into CD pipelines. They are pushing the boundaries of platforms like Selenium using services like SauceLabs. They are expanding their natural language approach to testing with Cucumber, etc. Coming from my developer background, I’m excited to see the practice securely taking hold in the testing arena. That’s one of the main reasons for the “T” in CITCON. We felt that CI wasn’t enough. We need the testers to unify around a common vision of keep the code working. We mean truly working, not just compiling!

So, join us in Turin for CITCON Number 21. Help us keep moving the boundaries of professional software delivery! See you there!

World Famous Pair Programming Talk!

December 29th, 2012

Back in 2007 I was contemplating what I wanted to speak about at conferences. I asked myself, “What do I feel strongly enough about? What do I really care about? What practices should everyone be doing?” Two things came to mind:

Advanced Continuous Integration (now we call this Continuous Delivery)

and

Pair Programming

Speaking at conferences can be a ton of fun. I recommend it for anybody working in the consulting field. That said, conference lecturing requires significant time and energy. This will come as a shock: You have to prepare! If you do not practice, then your audience will quickly lose interest. They will inevitably use the Law of Two Feet.

The topics that I was going to talk about had to be personally interesting. I had to have a passion for them. I knew I would be reusing (and continually refactoring) the presentation material for at least a year. I had no interest in signing up for something that would bore me senseless.

Pair programming in action.

Photo by Erwin Bolwidt. Your host, pairing at CITCON Singapore 2012.

CI (Continuous Integration) has been a fascination for me since the year 2000. Heck, I co-founded CruiseControl, mostly in my spare time, to scratch that itch. Beyond that, in 2007, Jeffrey Fredrick and I had one year of CITCON (the Continuous Integration and Testing Conference) under our belt. So all things CI were a natural fit.

A quick aside: Jez Humble and Dave Farley’s book on Continuous Delivery was still in the works at the time. I remember talking to Jez about the book, but I do not recall if the term Continuous Delivery was finalized yet. From as early as 2003 people were using terms like CI++, Advanced Continuous Integration, Continuous Deployment, Continuous Delivery, CI All the Way to Production, etc. For me, I wanted to talk about CI beyond setting up CruiseControl, or Jenkins, or AntHill, or Bamboo, or… (fill in the blank, 2007 saw a huge upswing in Continuous Integration platforms). Advanced CI would leverage my years of expertise. It was clearly a no-brainer. I needed a second talk.

I thought back to two practices we used on my last project in Detroit – TDD and pair programming. My colleagues at ThoughtWorks were already doing a bang-up job presenting on every facet of TDD. I also really enjoyed Uncle Bob Martin’s talk on TDD. I did not feel like there was much meat left on the bone. Pair programming was a different beast.

Pair programming was a frequently dismissed, overlooked, despised portion of the original XP white book. People would tell me that they had tried pairing, but hated it! I heard the same story over and over again, amongst colleagues and clients alike. I held quite the opposite opinion (and still do). I love pair programming!

What was I doing that all these other people were not? I am no smarter. I am no worse programmer, and likely not particularly better. I knew that I needed to suss out the core differences that made pairing a delightful endeavor. In fact, I hated programming without a pair.

Out of that came my talk entitled (usually) “Pairing with Pizzazz”. Sometimes I have called it “Pairing with PJ”. I have been doing this talk for five years. People love the talk. I love to give the talk. I make it fun by live pairing with people. I combine a little knowledge sharing with a little hands on.

I have given this talk at least 25 times, around the world. I have delivered it at big industry conferences. I have delivered it at smaller un-conferences like CITCON. I have presented it at internal company conferences. I have presented it at local user groups. I will probably give this talk publicly at least once in 2013, 2014 and 2015. And now I want to share it on my blog.

The presentation material consists mostly of pictures. I tell a story. I do not read bullet points! This will make it more difficult for readers seeing the material for the first time through the internet. Anyone with questions should email me@pauljulius.com. Both the PowerPoint slideshow and the PDF version contain some notes that I wrote when I was first thinking through the talk. That will help casual readers.

Feel free to read through the talk. Feel free to share it with colleagues. Please do not present this material as though it were your own. Do feel free to present it as though you heard about it from me and wanted to help make the world a better place.

Finally, for full disclosure, I did not invent anything new for this talk. I leveraged the expertise, experience, enthusiasm, passion, mistakes, dissatisfaction, and joy of hundreds of people with whom I have had the extreme privilege of pair programming. Thank you, everyone! (And Happy New Year).

Download the PDF version of the presentation.
Download the PowerPoint version of the presentation.
Email me with questions or just leave a comment on this blog entry.

CITCON Portland Registration Open

September 7th, 2012

CITCON Schedule in SingaporeThe Open Information Foundation is excited to announce that CITCON North America 2012 will take place in Portland, Oregon on September 21 & 22. CITCON, the Continuous Integration and Testing Conference, will almost certainly include a plethora of topics about the newest amalgamation term, Continuous Delivery. (Thanks to Jez Humble and Dave Farley for publishing their book and giving us a solid name for the evolving field!)

When we were at CITCON Singapore earlier this year we covered topics that varied from the classic, “What is CI?” to advanced techniques for testing. Some Singaporeans mentioned that the whole DevOps thing is just starting to take hold there. I am sure in no small part due to the efforts of the fine folks at the ThoughtWorks Singapore office.

In North America, though, the last few CITCON events have been focusing more on advanced Continuous Delivery topics. That does not mean that practitioners new to the field should shy away. On the contrary, they are the most important attendees in many ways. They challenge the thinking of old timers like myself. They make me re-rationalize things I take for granted, like the importance of the cup-of-coffee metric.

I enjoy witnessing the CI server evolution evident at CITCON’s North American edition. When I first approached Jeffrey about doing a 5 year birthday party for CruiseControl, I did not envision it evolving into the CITCON we have today. Thanks to Paul Hammant for helping to name the conference and pushing for a broader focus than just CruiseControl. As time passes, we see people using all the different CI platforms to accomplish Continuous Delivery. Surely, users will be present from the communities of Hudson, Jenkins, AntHill Pro (and maybe the newest addition, uDeploy), BuildForge, Bamboo, Go, ElectricCloud, CloudBees…not sure this list ever ends. Since I don’t have time to keep up with all of them, I learn boatloads about each just by listening to people tell me about their real world experiences.

I would be remiss if I forgot to mention the testers! Having emerged from the computer science/programmer/build lackey world, I find myself missing out on the hardcore testing advancements. I help my client’s quality assurance teams automate their world, based largely on the information I gain from being a part of CITCON. People like Lisa Crispin and Bret Pettichord have made their way to CITCON. Every year, I meet new innovators in the testing space.

Without testing, we would not be able to deliver continuously! And that’s where CITCON’s true power comes into play. We have the opportunity to bring together both these worlds in one room, for at least a day and a half. Many testers, sadly, do not get to spend anywhere near that kind of face time with the developers with whom they work. I love seeing that spark in a tester’s eye when they put together a plan in their head for how to help their teams back at the office.

I could go on and on, but it boils down to this. If you are a software professional that cares about delivering software repeatedly with ease and joy, then you belong at CITCON! Register now: http://www.citconf.com/portland2012/register.php

CITCON Raleigh Durham – Registration Open

February 8th, 2010

http://citconf.com/raleigh-durham2010

I wanted to let everyone know about CITCON North America in Raleigh Durham on April 16 & 17 because I co-chair the conference and the more of you that come, the better the conference becomes. This is the 5th year for the conference. We started the conference back when I was at ThoughtWorks doing CruiseControl work and JTF was at Agitar. It’s great to see new and old faces alike each year. Maceij from Urbancode described it as “an annual reunion of sorts”.

I love the open spaces format, largely because I have no idea what I will learn until I get there. I learn whatever everyone else is interested in. That’s an amazing way to take in new information. It’s humbling. In fact it reminds me of one of the first concepts I had to accept when I studying the philosophy of Socrates in university, “Before we can learn anything, we must first admit we know nothing.”

Can’t make it to CITCON RD? Then make it to one of the other ones – Wellington, NZPrague, CZSingapore.

CITCON, the Continuous Integration and Testing Conference, is an open spaces conference in its 5th year. The topics aren’t decided until the first night of the conference, but past events have proven extraordinarily useful to anyone interested in Continuous Integration and the type of testing that goes with it. Developer-testers, tester-developers, tool creators, and Agile advocates have all gained a lot from attending.

The conference is free to attend! You have to pay $20 to register, but you get that back when you attend the conference. (We are using long time conference supporter Obtiva’s EventWax for registrations. Just follow the registration link below.)

This year, the North American event will be in Raleigh-Durham at the Sheraton Chapel Hill Hotel. Registration is open, but limited to the first 150 registrants. Sign up now to reserve your spot at this innovative, exciting, education, fun event.

http://citconf.com/raleigh-durham2010/register.php

The conference operates as a non-profit, so our advertising budget is basically zero. We can use your help to get the word out. If you know someone that might be interested, please pass this announcement along to them.

Also, if your company or a company you know would be interested in sponsoring CITCON, there are a wide range of sponsorship options.

http://citconf.com/raleigh-durham2010/sponsor.php

If you have any questions, please don’t hesitate to contact me.

CITCON Paris Interview

October 19th, 2009
Enjoying the sites of Paris.

Enjoying the sites of Paris.

While I was in Paris for CITCON, I met up with my old buddy Julian Simpson, aka the Build Doctor. I admire what he has been doing with his blog and we always have a good time chatting about old times, the present state of the industry and where we are going.

Julian was interested in interviewing me for his site. I was interested in being interviewed.
http://www.viddler.com/explore/builddoctor/videos/1/

He also interviewed Jeffrey Fredrick.
http://www.viddler.com/explore/builddoctor/videos/2/

Jeffrey and I both talked about relationship with CruiseControl, CITCON and various industry leaders. I think both interviews are a lot of fun to watch. Julian was limited to 10 minutes, so we didn’t get to everything. Feel free to ask any follow up questions!

Cup of Coffee Metric for Continuous Integration

September 14th, 2009

How much can you learn in the time it takes to get a cup of coffee?

How much can you learn in the time it takes to get a cup of coffee?

What happens in the time it takes to get a cup of coffee can tell you a lot about the quality of your continuous integration system. Try something out for me. Commit some code. Leave your desk to get a cup of coffee, or some other tasty beverage. When you get back to your desk, do you know whether your changes were any good? No? Yes? I hope so, and so should you. It’s called the cup of coffee metric.

The idea is simple. In the about the amount of time it takes to get a cup of coffee you should be able to get information about the quality of your changes. Look at it this way. You just committed some work. You need a short break before you move on to your next task. You don’t want to wait too long, or you might find yourself surfing the web instead of writing code. So, leave your desk. Get a coffee. Take a bathroom break. See what’s hot around the water cooler. Once refreshed, return to your desk. You don’t want to move on until you make sure your last commit didn’t cause any immediate problems. A good CI system will support this behavior by giving you some feedback in about that much time.

The level of information may not be complete. Enterprise build systems are notorious for the length of their builds. Enterprise systems are also notorious for waiting to provide any feedback until the end of the build cycle. That sucks. A little information would be better than none. It might only be an initial piece of feedback, like “Your changes compiled!” If that’s all your CI system can get done in cup of coffee time, that’s better than nothing. Your CI system might tell you everything is going smoothly, only to return later to tell you something broke. No worries, sometimes that will be the case. Hopefully not always.

As a build engineer, I am going to try my darnedest to provide you with as much information as possible while you are getting your refreshment. That’s how I keep my team humming along. I might even use a “build pipeline” to help facilitate this sort of thing, but that’s an implementation detail. I am always asking myself, “What’s the most I can possibly discover about a commit within about 5 or 10 minutes from the time a developer presses the button?”

This idea came from Jeffrey Fredrick‘s real life experiences. He and I co-present on various topics. We talk about CI a lot at CITCON, of course. Invariably we discuss the cup of coffee metric when talking about evaluating CI systems. I stole the idea from him for use in my consulting. (Most of my good ideas come from our community. Thank you internet!) With his permission, I figured it would make sense to write it up for the world. So, here you go.

Enterprise CI Culture Maturity Model

September 14th, 2009

Last Friday, Jeffrey Fredrick posted my “guest” article on the Anthill Pro blog. The article reflects on a culture addendum to Urbancode’s Enterprise CI Maturity Model.

I use the maturity model. It has worked well for me. It works especially well as a communication tool with my clients. I was feeling, though, like something was missing. The aspects listed on the original maturity model were thing focused. Here’s an example, Historical Reports are listed on the Intermediate level for Reporting. Excellent point, and I agree. But that’s a thing. One could publish historical reports until they are blue in the face. If nobody looks at them, then what’s the point?

OK, so most of the maturity model implies some action, I know. I wanted to call that out a little more explicitly.

In fact, I wanted to bring out the People side of this equation. People over process, remember? Actually, People over Automation tools, should also be true. So, that’s what I did. I tried to pull together some People aspects that will help you gauge your company’s success. I hope it helps. As Jeffrey noted when he emailed the CITCON mailing list, he looks forward to seeing the maturity model continue to evolve. I do, too. I think it has the potential to level the playing field a bit and mediate the “tool wars”. Those wars cloud the real mission – working software.

Please read the full post. Feel free to comment there. I will be interested to see where we go from here.

Feature Branches are Poor Man’s Modular Architecture

September 3rd, 2009

As dusk falls on some beautiful architecture.

Melbourne skyline, as dusk falls on some beautiful architecture.

Martin Fowler just published a much anticipated (by me at least) blog article on Feature Branching and how it relates to Continuous Integration:
http://martinfowler.com/bliki/FeatureBranch.html

I really enjoyed the article and recommend it to anyone considering using a distributed version control system (like Git), or even the non-distributed ones that promote branching, ClearCase and RTC’s scm come to mind.

As a consultant, I have run into the branching nightmare scenario time and time again. In fact, I spend a lot of effort moving clients to mainline development. So, though feature branching and distributed version control system’s prolific support for it may seem new it has been around for a long time. In the past though it was typically born from necessity, not forward thinking choice. Usually I hear something like, “We had to create [feature] branches because the developers kept breaking everything.” Can you guess the result? The developers still broke everything, but all the problems were saved until the end of the project. After a hard code freeze there would be 6 weeks of branch merging, aka: Integration Hell.

I thought we (as an industry) figured out a better way back in `99 with the Extreme Programming white book – Continuous Integration! If it hurts, do it more often, not less. Don’t save up all the pain for one big blast. Spread it out, in tiny bits, over the course of the project.

So, why are feature branches still a consideration? Because continuously integrated code bases require some architectural craftiness. In truth, it can be challenging. Architecting big enterprise systems provides enough challenges on its own. “Now you CI guys want us to make the application modular?” (Actual quote)

Yep, that’s right. At the recent “How to be really awesome at CI” panel at Agile 2009, Tom Sulston chaired a panel including myself and several other folks with deep CI experience. A question was asked about how to achieve the “check-in every hour” mantra I was pushing, without breaking everything in the codebase. Yes, feature branches were mentioned. Feature hiding was mentioned. Modularization (componentization) was mentioned. There are lots of great ways to achieve this that don’t require you to put your team back into Integration Hell territory.

Fowler, in the aforementioned article, lands on:

I much prefer designing the software in such a way that makes it easy to enable or disable features through configuration changes. My colleague Paul Hammant calls this Branch by Abstraction. This requires you to put some thought into what needs to be modularized and how to control that variation, but we’ve the result to be far less messy [than] relying on the VCS.

I agree.

Refactoring CruiseControl Configuration Files (From Agile 2009 Demo)

September 1st, 2009

Building a stable CI system requires some crafty architecture, just like building a functional central business district.

Building a stable CI system requires some crafty architecture, just like building a functional central business district.

At Agile 2009, Tom Sulston refereed a “cage match” with all the Continuous Integration tool vendors available. That included me representing CruiseControl. Each vendor had 10 minutes to share a bit about their tool and take questions from the audience. I got to go first!

I decided to focus on a couple characteristics that distinguish CruiseControl. The things I chose were project pre-configuration and a usage pattern for supporting multiple projects. Here’s a textual version of the demonstration that I gave at Agile 2009.

Let’s start with the sample CruiseControl configuration that comes with the binary distribution when you download it.


<cruisecontrol>
    <project name="connectfour">

        <listeners>
            <currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
        </listeners>

        <bootstrappers>
            <antbootstrapper anthome="apache-ant-1.7.0" 
                     buildfile="projects/${project.name}/build.xml" target="clean" />
        </bootstrappers>

        <modificationset quietperiod="30">
            <!-- touch any file in connectfour project to trigger a build -->
            <filesystem folder="projects/${project.name}"/>
        </modificationset>

        <schedule interval="300">
            <ant anthome="apache-ant-1.7.0" 
                buildfile="projects/${project.name}/build.xml"/>
        </schedule>

        <log>
            <merge dir="projects/${project.name}/target/test-results"/>
        </log>

        <publishers>
            <onsuccess>
                <artifactspublisher dest="artifacts/${project.name}" 
                       file="projects/${project.name}/target/${project.name}.jar"/>
            </onsuccess>
        </publishers>

    </project>
</cruisecontrol>

That works great to have a little sample project running out of the box. Now, I want to add another project. In this case, I am going to use HttpUnit. I checked it out from subversion in my projects directory. After that, I need to configure CruiseControl to run the build for it. I’ll start by copying and pasting the project configuration used for the connectfour project. I only need to change one thing: the location of the final jar file. Instead of the jar being built into the target directory, it goes into the lib directory. So now, our configuration file contains the following after the end of the connectfour project definition.


    ...
    <project name="httpunit">
    
            <listeners>
                <currentbuildstatuslistener 
                    file="logs/${project.name}/status.txt"/>
            </listeners>
    
            <bootstrappers>
                <antbootstrapper anthome="apache-ant-1.7.0" 
                    buildfile="projects/${project.name}/build.xml" 
                    target="clean" />
            </bootstrappers>
    
            <modificationset quietperiod="30">
                <filesystem folder="projects/${project.name}"/>
            </modificationset>
    
            <schedule interval="300">
                <ant anthome="apache-ant-1.7.0" 
                    buildfile="projects/${project.name}/build.xml" />
            </schedule>
    
            <log>
                <merge dir="projects/${project.name}/target/test-results"/>
            </log>
    
            <publishers>
                <onsuccess>
                    <artifactspublisher dest="artifacts/${project.name}" 
                        file="projects/${project.name}/lib/${project.name}.jar"/>
                </onsuccess>
            </publishers>    
    </project>
</cruisecontrol>

That will work. Both the connectfour and httpunit projects will build in CruiseControl. Looking at the full configuration file, though, makes me feel a little ill. The file contains a ton of duplication. As noted, the only thing that differs between the two is the location of the project distributable, i.e. the jar file. Let’s refactor that a bit to pull out some of the duplication.

For CruiseControl, we can take advantage of the plugin preconfiguration features. Projects are plugins. So, we can extract all the common elements to a project “template” that all our projects use.

Within the individual projects we can override the elements that are unique to that project. Sort of like creating a base class in object oriented programming. Subclasses extend the base class and override the methods for which they need to define explicit behavior.

Here’s the full configuration file after the refactoring:


<cruisecontrol>
    <plugin name="project">
        <bootstrappers>
            <antbootstrapper anthome="apache-ant-1.7.0" 
                buildfile="projects/${project.name}/build.xml" 
                target="clean" />
        </bootstrappers>

        <modificationset quietperiod="30">
            <filesystem folder="projects/${project.name}"/>
        </modificationset>

        <schedule interval="300">
            <ant anthome="apache-ant-1.7.0" 
                buildfile="projects/${project.name}/build.xml"/>
        </schedule>

        <log>
            <merge dir="projects/${project.name}/target/test-results"/>
        </log>
        
        <!-- Publishers are up to the individual projects for now. -->
        
    </plugin>
    
    <project name="connectfour">
        <publishers>
            <onsuccess>
                <artifactspublisher dest="artifacts/${project.name}" 
                    file="projects/${project.name}/target/${project.name}.jar"/>
            </onsuccess>
        </publishers>
    </project>
    
    <project name="httpunit">
        <publishers>
            <onsuccess>
                <artifactspublisher dest="artifacts/${project.name}" 
                    file="projects/${project.name}/lib/${project.name}.jar"/>
            </onsuccess>
        </publishers>    
    </project>
    
</cruisecontrol>

That’s a lot better. Now the projects share a common template. They each define their own publishers, which allows them to override the location of the jar file.

One more step. The project definition could be extracted from this central configuration file and included with the files that the project owns. I use the include.projects plugin for CruiseControl.

I like to create a file right next to my build file, e.g. build.xml in the case of Ant. Then the project, or component if you prefer, team can take ownership for their project definition. As a CruiseControl administrator, all I have to do is point to their configuration to include their build in a particular CruiseControl instance. Here’s what my main configuration file looks like after that change:


<cruisecontrol>
    <plugin name="project">
        <bootstrappers>
            <antbootstrapper anthome="apache-ant-1.7.0" 
                buildfile="projects/${project.name}/build.xml" 
                target="clean" />
        </bootstrappers>

        <modificationset quietperiod="30">
            <filesystem folder="projects/${project.name}"/>
        </modificationset>

        <schedule interval="300">
            <ant anthome="apache-ant-1.7.0" 
                buildfile="projects/${project.name}/build.xml"/>
        </schedule>

        <log>
            <merge dir="projects/${project.name}/target/test-results"/>
        </log>
        
        <!-- Publishers are up to the individual projects for now. -->
        
    </plugin>
    
    <include.projects file="projects/connectfour/cruisecontrol.config.xml" />
    
    <include.projects file="projects/httpunit/cruisecontrol.config.xml" />
    
</cruisecontrol>

Then, the project team gets to own the cruisecontrol.config.xml file. The one for httpunit looks like the following:


<cruisecontrol>
    <project name="httpunit">
        <publishers>
            <onsuccess>
                <artifactspublisher dest="artifacts/${project.name}" 
                    file="projects/${project.name}/lib/${project.name}.jar"/>
            </onsuccess>
        </publishers>    
    </project>
</cruisecontrol>

The httpunit team can version that file as an artifact important to their project, just like the build file.

As a CruiseControl administrator at a big company, I might have tens or hundreds of different projects that I want to include in my server. I also might want to include the same project in lots of different CI servers. Extracting the project specific definitions allows me to do this with ease!

CITCON Paris 2009 Almost Here

September 1st, 2009

CITCON Paris, the European instance of the Continuous Integration and Testing Conference, is just around the corner. Our registrations filled quickly and we had to put quite a few late registrants on the waiting list. The committee has begun the task of sorting through the waiting list now. We hope to accommodate as many as possible.

For those attending, I’ll see you in Paris.

If you can’t make it to this event, keep an eye on the CITCON website for 2010 events in North America, New Zealand/Australia and Europe.