GranitTreff #2

Besonderer Dank geht an bluesource mobile solutions gmbh unseren virtuellen Host für die Unterstützung bei der Organisation dieses Events.

::Agenda::

::Git in Software Engineering::
Thomas Herzog

Git has taken the software engineering world by storm and is nowadays the number one VCS tool in use. But Git as a VCS tool alone is not enough, we need workflows that help us to organize our work within Git as well. This is where Git Branching Models and Workflows come into place, that help us with organizing our work within Git and
how we can reintegrate changes back to the mainstream.

When we use Git Branching Models we work separately on feature branches, whereby we want to be capable to deploy our feature branches to an environment such as Kubernetes for testing or user acceptance tests. But how are we supposed to distinguish our feature branch deployments in the environment when all deployed feature branches are supposed to be released with the same version when they are done? This is where we need to learn that branch names must be capable of being translated into a unique version. For this we need to use a Git Branching Model which defines naming conventions for branches and what they are used for.

During the talk, I will bring you close to Git, Git Workflows, and Git Branching Models, what there intend is, how they work, and how you and your team can profit from them in a software engineering project. I will show you branches and their related versions in action in a CI/CD environment with Github, Docker Hub, Docker, Jenkins, Nexus, and Kubernetes.

::TDD, CI/CD for infrastructure as code with footloose, ignite, and firecracker::
Martin Ahrer

For the past 2 decades developers have shaped their development process into something that we call continuous delivery.
They apply TDD to have tests that give enough confidence for delivering software fully automated.
As containers arrived, developers had tools at hand to reduce build pipeline runtime and write code for implementing the application's runtime infrastructure.

Wouldn't it make sense to apply the same principles to infrastructure code? Can we practice TDD and CD for infrastructure development?

In this session we discuss why we might fail when attempting to employ traditional virtualization technology when developing something as complex as a cluster of many machines.
We will be using Vagrant to fire up a bunch of machines, will write server specifications, use Ansible for provisioning and execute tests using Chef inspec.
Then we will abandon those virtual machines and go on a journey through tools like footloose, ignite and firecracker.
We will use drone.io for a CI/CD pipeline for testing/deploying firecracker machines.

::Build.WithConfidence();::
Bernhard Mayr

on API design, fluent interfaces and the builder pattern

Because this (^) is not an abstract, here is the blazingly technical table of contents of this session:

• autocomplete and static types as a navigation system (AaSTaaNS)
• How to write a library with git in mind?
• writing code vs. reading code
• Why I am studying psychology...
• "Oxford English Dictionary" - my new favorite dev tool

::Thomas Herzog::
Cloud Architect & Lead Developer @ gepardec IT Services GmbH

::Martin Ahrer::
Martin has 30+ years of experience as software engineer and spent the last 20 years building apps for the Java platform. He is a co-founder and president of the Enterprise Java User Group Austria.
Before Docker 1.0 hit the market he had already used it for implementing CD pipelines and has supported numerous customers with introducing Docker in their development processes.
Since 2016 he has given lectures on "Infrastructure as Code with Docker" at the UAS Upper Austria - Campus Hagenberg to master and bachelor students.

::Bernhard Mayr::
developer, software architect, psychology and philosophy student, former software engineering student, future mobile computing student, type enthusiast, loving simplicity and minimalism