See the gathering page for our next gathering.
Here is a list of our recent initiatives and topics we can dive into in the 8th gatering. Any member can participate in forming the agenda in our Code Alliance Slack team.
Jenkins as Code
The new Jenkins as Code is a quick-to-start and easy-to-use solution with an optional Docker setup.
By putting it into a plugin and separating configuration files - it’s up to users to decide where to store them and how to maintain them - we make it much more comfortable to use and keep up to date: all new features will come with plugin updates that won’t compromise configuration.
Lightweight Docker setup will make it even easier to start and maintain but isn’t obligatory. A plugin can be applied on already working Jenkins instances, no matter how it is hosted.
It is matured a lot since the 7th gathering and is now first class project in the Jenkins community taking a lot of interest and focus.
We believe it is production ready and we’re rolling it out now.
Managed OPS done right in the cloud or on-premise utilizing a large open source ecosystem.
Praqma’s Oslo office is ready to introduce our Infrastructure as Code platform, how it is funded, its current status and roadmap.
ASK - Atlassian Software in Kubernetes
Running Atlassian products in a way that makes your operations impressed.
We will present how to run the Atlassian Data Center toolstack in Docker with Kubernetes to bring the strength of Data Center and Kubernetes together: Scale horizontally and get resiliency; Everything is described as code; Upgrade Jira with zero downtime and scale to meet demands in seconds. ASK also supports Atlassian Server editions.
Your developers should be in control of the version bumps.
Who knows what the next version should be? Independently from your version scheme, it is always the developer who should have the last word in these matter, as they will be writing the code that makes your project break backwards compatibility.
It could be as easy as the developer using smart commit message by including phrases like “Bumps major” or “Patch bump” and then letting the wincrementor tool do the house-keeping of the next version of your project.
That is an automated approach!
We’re ready to demonstrate the concept, and one implementation of if.
Build and CI metrics
We have themed the 8th gathering dedicating day 2 to metrics. We will dive into the many aspects and ideas about build and CI metrics. Which metrics are we using? Which would we like? What do we want to use them for? Are there any good standards and reuse.
Metrics of all kind is a topic that keeps coming up over and over again - everyone want metrics for their software development.
On our last Gathering it was our largest break out sessions on the 2nd day, where the theme was traceability but metrics was drawing a crowd. There wasn’t any conclusions or any common projects kicked off, and we can easily dive deeper into metrics.
We believe actionable metrics is important and we can focus on these. We propose to discuss metrics that we can actually react to, and not just metrics that shows nice graphs. Something with clearly defined ways to interpret and guidance towards fixing the issues the metrics reveals. The actionable metrics should preferably be for both managers with planning aspects and developers with technical aspects.
It would be really interesting if as many of you as possible could come up with a short lightning talk of what you really would like to have metrics on and what you would use them for.