Dockery added to the official Docker documentation as client library

I'm proudly announcing: my simple Docker management application Dockery is added to the official Docker documentation as remote api client library. It started as a pet project to learn some Angular basics as a notorious backend developer, but somehow it turned to a fun and my colleague Jens Wlodarczyk convinced me to take it more seriously and popped up the idea to create a Chrome app version too. That wasn't easy for a novice javascript learner, but now it used by other guys around the Earth and I'm getting feedback about what to improve/fix. This is my very first travel into the open source community and I think this is a great source of motivation and gives me extra energy to work on it. The blog of course will focus on different things, but this is a great achievment for me and I'm moved a bit now. Sniffsniffsniff... :)

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.

Dockery Light released as Chrome app

I recently released the beta version of my Docker management application Dockery Light (I'm still working on the name/branding hehe). The app is quite beta, but able to help you as developer to manage docker hosts via the remote api. 

All feedbacks, bug reports, critics, enhancement ideas are warmly welcome :)

You can add to your Chrome browser via this link.

Feel free to fork it and send pull requests: Github repository 

Few words about docker volumes

Docker volumes | Create infographics

Why Codecademy is cool

I recently finished the Python course on Codecademy and I'm thinking on how to say thank you for it to them. Not just because the site is great and I already found the next course (as a back-end developer I need to practice front-end things at home to not be a specialist of one thing) to continue, but by their approach to letting me to learn python on very entertaining and easy to understand way. I see how much effort invested into the site just to provide free material and how professionally designed the page and the learning flow. The Pythong material is well structured and introducing step-by-step from the basics to the real pythonic things. And you get a chance to write a game during the course!

What I liked in the Python lessons as a notorious Java developer?

• The for-each loops. Especially when I can add an enumeration to track the index. In java if you need you had to avoid for-each and use regular index based for.
• Else case at the end of the loops. That's a brilliant idea to separate the implementation for the successfully finished looping or the cancelled ones.
• The in keyword. Python has a more generic approach to check the existance of an item in a collection/dictionary/array/etc..
• List comprehensions. I love to populate data in a readable, one-liner format

I think I have a basic knowledge about some of the language elements (first steps :) ) and I need to move forward the more complex topics. Not only on language level, but I'd like to see Python as platform to deliver a complete solution to a problem. I already bookmarked some Youtube videos about the advanced topics, but I hope I can find some blogs or tutorials about how to start a Python project and end up with a successful delivery.

Beware of outdated books

I'm really amazed when I found on Amazon a very old book from Martin Fowler: Patterns of Enterprise Application Architecture. I have this book and I rechecked my assumptions and found this book is badly outdated. I mean most of their suggestions and patterns are already implemented in several frameworks (spring, spring-mvc, hibernate/jpa, etc..), the current architectural solutions are stepped over on it, but the price is still high. Maybe they keeping them for the collectors or multi-millionare developer veterans :) 

Currently the IT sector is growing quickly and lot of newbies are arriving to train themself to the next Peter Norton (Is anyone knowing him? :) ), Larry Page (better known) or Guido van Rossum. Thanks to the internet, voluntarism and the open source community we can learn almost everything for free, but some of us need to buy some paper books to erect a statue of our learning efforts.

I don't really know what should Amazon do with these books, but it alerts me to read all reviews carefully even if it written by trendy/famous authors to avoid traps like this.