Golang basics for Java developers

I put together a quick introduction to my Java colleagues into Golang to make some appetite to try it out. This presentation is the first in the series of Microservice development with Golang and focusing on the language elements sprinkled with example code links. It tries to compare them with Java to help the easier understanding, why Go has a potential in enterprise environment even in private/hybrid or private cloud scenarios with low resource usage and efficient concurrency.

Pull request build automation for Stash with Jenkins

Intro

Moving toward the frequent releasing is a challenging goal for all organizations. It needs well crafted delivery pipelines, devops mindset to take care about the whole software delivery lifecycle and also needs efficient tooling and methodology from the beginning. The starting point is the definition of a supportive workflow for your SCM. We are using Atlassian Stash as Git server, therefore I looked after for Git based workflows. Click on the links for the detailed description of these workflows, the Atlassian guys made a great job to explain them.

Jenkins DSL scripting - Part 4 - adding our own library to the DSL plugin /TL;DR/

Intro

This is actually the last part of my series about Jenkins DSL scripting. I already discussed the basics with environment setup, job creation and linking, view definition and the importance of the easily reproducible build pipelines with non-pet Jenkins servers. The following part I explained some more advanced topics, like the interaction with the environment, credentials and the customization options with configure block

In this part I'm talking about how to extend the plugin's functionality with your own commands and implement complex logic behind it.

I'd like to say a REALLY big thank you to my colleague Thomas Schneider for his approval to reuse his code snippets and findings in this blogpost. Respect!

Jenkins DSL scripting - Part 3 - intermediate /TL;DR/

This is the third article in my series about the journey of Jenkins DSL scripting.
In the first part we learned the basics of the DSL plugin features with detailed explanation of the building blocks to enable you to create simple pipelines.

The second part described the side effects of dynamic pipeline creation, the role of seed/boostrap job and finally demonstrated and described a simple pipeline project for an application. They were the basic part of DSL scripting and focuses on the pipeline as a whole.

Now we are entering to the intermediate level and focusing on particular problems of the pipeline creation like passing values via environment variables, using credentials to access protected resources, extending the DSL plugin functionality with the configure block to use non-covered plugin functions and so on. 

Jenkins DSL scripting - Part 2 - environment setup /TL;DR/

In my first article I wrote about the basics of the Jenkins DSL scripting. I explained my motivation to switch from static Jenkins configuration to a more dynamic one and tried to show the benefits via small examples.

In this part I'm talking about some interesting side effects of dynamic pipeline generation, the role of seed jobs, my development setup and finally I define a basic pipeline as a blueprint for other's project. I hope this entry will be shorter then the first one :)

Jenkins DSL scripting - Part 1 - basics /TL;DR/

As the Continuous Delivery is spreading, more and more CI servers are working on daily builds, tests and releases. With the growth of the companies' codebase we are repeating almost the same steps with slight changes to implement CI/CD coverage for the new modules and projects, but the maintenance or update of these steps is getting harder. In a monolithic environment the growth is not so remarkable, but as we are moving toward the microservice paradigm with containerization, the maintenance effort of these configurations could jump quickly.

The majority of the servers I saw was run the same sequence of checkout, build, package, deploy, tests steps and finally marked artifact as releasable or released it into the production environment.

Also all of these servers were guarded by intensively and only some chosen ones were able to change configs or could consider to upgrade to a more recent version with shaky hands and unpredictable compatibility issues. We could agree on the high importance of these servers and their unique role, but how could we mitigate the risk and dependency on these servers? How could we repeat pipeline assembling steps in a reliable way and make predictable the outcome?

Purpose of this document

This is the first part of the series of tutorials about Jenkins scripting to achieve a fully automated, decentralized and replaceable delivery pipeline architecture with better flexibility than the monolithic, centralized Jenkins setup. In the series I’m talking about the scripting basics (here), some intermediate steps (xml configuration, modularization, common tasks, DslFactory, etc.) and the extension of the plugin function with own library routines. In this part I’m explaining only the basics of job and view creation, the syntax and a basic pipeline generation with some recommendations.

Few words about docker volumes

Docker volumes | Create infographics