November 2018 meetup

Agenda:
17:30 - 18:30 Walk-in
18:00 Food & drinks
18:30 The evolution of a Delivery Pipeline at scale
19:30 Break
20:00 Continuous Delivery as a cultural shift
21:30 Wrapping up

--------------------------------------------------------------------------------------------------
In order to get access to the building you have to bring a valid ID (passport, ID card or drivers licence)

You can have access to the guest wifi network based on your email address. To enable this send an email to amsterdamcd@gmail.com stating that you want access to the wifi network. Please do this on the day before the meetup at the latest. This to prevent all the hassle during the meetup.

Location, food & drinks brought to you by: Belastingdienst

Talks:
Aino Andriessen - Belastingdienst - The evolution of a Delivery Pipeline at scale

At the Belastingdienst we're developing a few hundred applications to collect taxes, support customs and payout allowances. The social impact and the political aspects are major concerns for the organisation of our processes.
We're currently in the middle of a journey implementing CICD to make the business more agile and in-control when responding to (political) change.
In this session we'd like to share our experiences, motivations, decisions and lessons learned from this continuous journey.

Biography:
Aino Andriessen now works as a Continuous Delivery specialist at the Belastingdienst. Before that, he worked for 20 years as an Oracle and Java consultant with a focus on craftsmanship and software delivery.

Mykola Gurov - Bol.com - Continuous Delivery as a cultural shift

Deploy continuously, move faster. But why? Why change things that work? What are the benefits for the teams and their stakeholders? Does this also apply to crucial back-end systems, or shall they rather move slow?

Meet the PUR team of bol.com. We support the Supply Chain operations of one of the the largest webshops of the Benelux. That is, the purchasing and communication with the suppliers goes via our services. Despite being mostly busy with a classical back-end "system of a record", we got our development process drastically changed over the course of a year: from infrequent releases of long-living branches we switched to the trunk-based development coupled with a high rate of deployment to production (dozens a day).

The transition was driven by the continuous improvement cycle as a response to the business and technical pressure with the given constraints. We simply aimed at reducing the cost of delivering a change.

The biggest obstacles appeared to be behavioral, not technical. Even the goal of keeping the master clean and production-ready was easier agreed than done.

As testing was quickly becoming a bottleneck, we had to rethink the way we test software and the role of our tester in this process. We shifted the weight of testing from staging environments to production and the dev/CI build. It was now the responsibility of the developer to ensure the quality of the shipped software, and the tester stopped to be a gatekeeper.

Continuous investment into the maintainability and resilience of our systems was a direct need of facilitate such changes. Extensive use of feature toggles allowed us to gain much flexibility by decoupling code deployments from feature releases.

From the business side, the commonly expected direct and simple effect of such transition — much faster delivery of the business features, wasn’t actually seen. We’ll discuss the reasons and what was the observable benefit.

Biography:
Mykola is a java backend developer (calls himself full-stack, of course). He has a strong interest in CI/CD and everything that helps to move faster without breaking too many things. Within bol.com he is known for the popularisation of using docker for system integration testing.

Parking:
Free parking at the building