Don’t go to conference!

The title is from a pitching session in Continuous Integration and Testing -conference (CITCON18) by Open Information Foundation. The announcer of the pitch wanted to create discussion about benefits of traditional conferences versus Open Space events. CITCON itself represents an Open Space format event, which is an awesome way to share ideas and networking for IT professionals.

CITCON gathered in the spring of Vienna, Austria, this time with around 60 people, of whom six were Hedgehogs from our Software Automation Tribe. Open Space events are most effective with 50-100 people, since the sessions are organized on the spot in an agile manner. The participants are mostly software and testing specialists, but the topics contain more human sciences than you’d find in traditional IT conferences.

The event starts with a quick introduction of participants. Followed by inventing short pitch talks about the topic for upcoming discussion sessions. You are allowed to present one pitch at a time, but can you join the line of presenters again after you are done with your first pitch. People are also encouraged to ask clarifying questions if the idea is hard to grasp. Post-It notes with the topic candidate are added on a whiteboard after a pitch is made. Each session is meant to last one hour.


Tommi Oinonen pitching his session topic

When the line of presenters had finished, the amount of Post-It notes had grown up to around 50. Next, everyone could vote on the topics their are interested in with a pencil, but only one vote at a time. There were five time slots and five rooms booked for the sessions next day. Hence, there were 25 sessions in total. When all the voters had visited the whiteboard, the most popular topics began to move to a timetable chart. This happened also in a self-organizing way, meaning that everybody could move the notes and the most voted ones found their time slots. Similar topics could end up bundled into the same session. The final timetable might not have been formulated earlier than just before the sessions the next day.

The time table is then used by people to plan their attendance to different sessions. However, the most important rule with Open Space sessions is the law of two feet: If the current session isn’t interesting, leave it.


Agile timetable

The sessions were held in classrooms, where chairs were organized in a circular form in order to maintain best possible connection between participants. The classroom also contained a white board for demonstrating purposes. The topics varied from more technical software problem solving in IT to sea shanties (!?). The most popular topics were about communication skills in work life. These sessions were facilitated by professionals, who also solve those issues in their everyday work. The session I liked the most was one where communication related challenges were asked from the participants and then solved via a role playing style dialog.

As an example of a more technical session topic, Tommi Oinonen from Siili wanted to obtain insights about his master’s thesis pertaining to metrics of software test automation and version control. Tommi truly achieved some good philosophical conversation and opinions to bring home from CITCON.

If I had to list some negatives about this Open Space event, I felt that people were even too eager to create session topics. Some general level subjects without deeper focus on some strictly defined problem ended up leading conversations into an academic monologue.

Open Space events encourage people to create sessions of their own kind where everyone can have interesting discussions. Compared especially to lecture-liked conferences, interactions between even shyer engineers increases. As an organizer encapsulated in his opening speech: If you did not get what you were looking for here, blame the organizers, that means yourself!

Pekka Rantala

Evolution of CI/CD pipeline

Back in the days there weren’t any tools for continuous integration or delivery (like Jenkins or Ansible etc). There was only ad-hoc build, manual testing and deployment done by developers from their own computers – and that was suprisingly ok (or they actually didn’t know the power of CI/CD tools yet). Actually it’s fine even today if we are looking CI/CD pipieline from a Lean perspective: to automate only the necessary parts of the value stream to get things done, BUT remembering to measure and improve the processes if needed (by creating a feedback loop and continuously measuring the process in retrospectives).

Sometimes it would be better to make your own tools instead of forcing to use ready made ones. I remember the times before Ansible when I was scripting a bit vague deployment pipeline with Powershell to deploy some PHP and Java artefacts to Windows environment alongside of .NET stuff packed into Nuget packages over TeamCity and Octopus Deploy. I know that was pretty questionable solution and I’m sure I’ll not do that again, but in the moment it felt a good enough (compromise) and I learned pretty much what it is to build things pretty much from the scratch. I found that a complex CI/CD processes could be an indicator of massive technical debt or cultural or process problems – but anyway, it was working and what was the most important thing. Customer got the solution and our team delivered a working software to production many times in a day.

Nowadays CI and CD pipelines can be presented as a code and stored to the VCS instead of managing configurations from the tool’s own GUI. Presenting configuration as a code is good because e.g. Ansible/Docker/Jenkins configurations are as valuable as the code of the main business logic and it’s fair to manage them over the same processes (for example pull requests, show-and-tell sessions , testing etc.). That approach turns the focus on the actual value and leads the change closer to DevOps culture.

Another good thing of modern CI is easier parallel processing set up. Today it’s possible to bring a flexible amount of Jenkins slaves in Docker containers if needed, or execute unit, integration and system tests in parallel by various tools like Gradle, Selenium Grid2 or Robot with pabot (for parallel end-to-end testing). Of course the cloud based CI services like Travis or CircleCI are pretty handy tools when project is suitable for using them.

But still the basic idea for me is to see the CI/CD pipeline as a part of the value stream. It’s all about choosing the right tools for the right case, or crafting the own tools if there’s no suitable one available.

More about configuration as a code: