This November the Continuous Delivery Alliance gathers for the 7th time. Do you want to join forces with some of the best people in the world of Continuous Delivery and collaborate on the next generation of tools? Then join the Alliance!
If you’re a member of the Alliance you should join our planning effort to discuss whatever’s on your mind - current frustrations, success stories, or great ideas for new tools. Go to our CoDe Alliance slack channel.
If you’re not a member you need to get an invitation because CoDe Alliance is by invitation only. Have you got the right stuff? Check out the next gathering and how to join.
Traceability is the theme of the next gathering
This time we have expanded the program to two full days (November 13th and 14th). The extra time will allow us to really dive deep into traceability. We will explore how to measure continuous delivery in your organisation by utilizing all the data you generate daily from your toolstack . Maybe the buzzword should be “big data!
Within Praqma we have been looking into this for a while, and several efforts have been made available in a proof-of-concept state.
The Tracey effort is one of them and it uses a message bus and the Eiffel protocol (as in a protocol, not the programming language) to create traces from the tools involved in continuous delivery. It could be used for event-based triggering, or used for visualization of interesting metrics or relations.
Our QuTiCon project is also about visualization, but the focus here is on displaying time series data to measure typical trends over time. We also have a collection of ELK scripts helping with the same data metrics. Our vision includes answering questions like “Where is my commit?” assuming you have described your process first, or “How long time does it take for a bug fix commit to get released?”
We see many of our customers, most of them members of the CoDe Alliance, investigating or directly working on things like these. We’re involved too.
There is room for both research and investigations, as well as a lot of work we could share and reuse to come up with a good project to benefit all members. So, on day two, we plan to have workshops around these broad topics, but we will also have to dive into details and be concrete.
We will facilitate some workshops and start by setting out the complete architectural overview of all the pieces we think belong in this area, and how they work together. This will give us a plan to work from. We also hope to bring the latest intel from the Eiffel community, as we will be joining their Eiffel Summit 8th of November. The Eiffel protocol could easily be a big player in this picture.
There is so much to do and so little time
The current program is online, but there isn’t enough room there for all the interesting things we want to work on and share. The program isn’t fixed - there is room for improvisation - so I’ll quickly mention all the other things that we will probably want to work on.
These are all potential topics for the second day of the gathering that could end up in hackathons or workshops.
Atlassian Software in Kubernetes
The Atlassian team in Praqma is always up for good solutions. Recently, they solved the problem of a monster application suite that is hard to deploy and maintain compared by beautifully wrapping it in containers and orchestration with Kubernetes.
The team will proudly present ASK - Atlassian tools wrapped in containers ready to deploy, even with High-Availability and Data Center support. This is so cool that your IT-department will be green with envy. Our effort is made possible by the Ops guys allowing the Devs to maintain and run their own tools.
We have a great plan and a roadmap for further work - join the journey.
“PlusBump” is the general project name of our automated version bumping tool.
Who should know when you break compatibility backwards? Who knows if a delivered change should bump the minor version? Who decides if a little change in, say, a docs file, constitutes a patch?
The answer to all of these questions is - the developer. Not the scrum master or the product owner. So, imagine the developer puts magic words in the commit messages with the change, like “bumps major” or “bumps minor”. We then apply automation, like we always do, and let PlusBump collect these entries and maintain knowledge of the next version.
This means no more need for difficult decisions on version bumps, and no need to run version bumps through your pipeline late before a release.
This tool is in POC state and could easily be taken to production state in a joint effort. Have a look!
Bill of material Gradle plugin
If you think software product lines, and you build your products from components, this is for you.
We made a custom Gradle plugin to handle dependencies in products consisting of components. The plugin helps you to report and document the bill of material of what actually went into the release of the product.
It’s not open source yet, but we have made it available for an alliance member and we see great potential in a shared roadmap for the future of this project. It will be a roadmap informed by a year of experience of working with dependencies in continuous delivery, so it is ambitious. Join forces with your fellow members and make your contributions to the cause.
Git Phlow and Pretested Integration Plugin
We launched this plugin after the 6th gathering, and we’re now ready to bring the Git Phlow to Jira and Windows. We also want to target Jenkins pipelines with the Pretested Integration Plugin for Jenkins.
If you don’t know the Git Phlow, it’s the easiest way to work with Git in an automated git branching context aimed for Continuous Delivery. Git commands come from the git-phlow git extension and the automation comes from our Jenkins plugin. Read more about the Git Phlow.
All of these recent development efforts are funded by one of the members of the CoDe Alliance and made available as open source. They build on a foundation made years ago by other CoDe Alliance members.
However, with a great tool comes great ideas, and we see new features appearing all the time. To maximise our potential it’s important for all members to share ideas and contribute to funding stages on the roadmap.
Jenkins As Code
Jenkins as Code makes your Jenkins server configurable purely as code. It’s kind of a proof-of-concept, but still runs in production with different customers of ours.
The project evolved and we’re now aiming for a complete revival of the product (we will omit the “reference” part) as we move away from the “clone-and-own” approach and look to build in ease of maintenance and deployment.
We will separate the “what” from the “how” and so Jenkins will be Jenkins, but configuration will be applied by a new configuration as code plugin. There’s no danger of breaking builds and compatibility with plugins and upgrades, you can test easily before pushing to production.
We have a demonstration ready for the gathering and a roadmap for the future. We even have CloudBees - the company behind Jenkins - attention on this so the potential seems great.
Wrap up, deliver, work on, wrap up, deliver…
We’re ready for the 7th gathering and have enough content for many more days than the program allows, so with the above teasers I hope to inspire you to either join our alliance, or, as an existing member, get involved before or during the day on some of the many ideas and topics. Obviously you’re going to join us - right?
After the gathering, we’re ready to roll up our sleeves and get to work … git phlow workon, git phlow wrapup and git phlow deliver, git phlow workon… (if we use the story behind the git phlow)