Flame it on me

The other day I was working for a company that hired me to upgrade their software factory to a Continuous Delivery setup. One of the questions of the developmentteams was to introduce Git as a replacement for SVN. Working for a fairly big organisation that is traditionaly formed I had to consult the Solution Architect. Solution Architects are people living in Ivory Towers who haven't written software for a long time or never made their hands dirty anyhow.

So I filed a request to setup some Git and Gitlab to let my development teams try it out and see if it would suit their needs. In the request we made clear what the advantages would and could be; including easier branching and better merging, and we thought we had a strong case.

Then we recieved the verdict and I quote: "It requires too much effort, and does not conform with our rules on branching, merging and versionmanagement. The transfer to Git doesn't support a clear goal. Branching and merging should be an exception instead of a rule".

[silence]

Where did these people live for the last eleven years, under a rock? Developers shouldn't branche? Merging is hard therefor we should not do it? No... merging is easy with Git therefor we shouldn't be afraid of it anymore. If you are afraid of something, do it more often. Branching is part of a good delivery strategy in build pipelines, which make you flexible. Too bad I'm not their manager, I would fire all architects that are not up to date with newest developments.

In the reply he also wanted to know how Git handles binaries in contrast to Subversion. OMG, realy? Binaries? Why? FFS? Yes, these files can be placed in Subversion or Git, but why would you do that? There are binary repositories that can handle these kinds of files way better than code repositories. Isn't that what we learned in kindergarten?

And as last argument he raises that it is already a problem to get non-functionals done within the teams. For one I'm doing the change, team impact is minor; they need to install git and pull. Second it seems that everyone always uses the non-functionals for exchange and to implement last. Non-functionals are most of the time acceptance criteria that can be automated, this should be implemented in the factory at the start of the project. Not used as change money.

Please let the solution architects find some solution to disolve in, I've had it with them.

Puppet

When operations needs an installation manual, wouldn't it be better to provide them with the exact instructions on how to install? Yes, we use Ansible or Puppet!

Linkdump for Hello World with Puppet: https://www.scriptrock.com/getting-started-with-puppet-labs

Managing Windows machines from Linux

To manage machines is one thing, but logging in to Windows machines with RDP seems a total waste of time to me. So I need something else. Just headless machines maintenance from a linux host with Python.

For communications with the Windows machines I will use wmic.
http://www.iggyt.org/doku.php?id=wiki:infrastructure_tools:wmi:wmi-linux_client-wmic

After installing with yum I make a virtual environment with my favourite user and install wmi-wrapper
https://github.com/kanzure/python-wmi-client-wrapper

Powershell unit-testing

Last week I started Powershell. As a luser I'm spoiled with the Linux command prompt and cram testing. Powershell is the same but different. Since I'm bound to the evil OS supporting Powershell I thought to myself, why not have a look into it. Batch-scripts are way too limited, echo'ing something to the screen is about as much as one can do with it. So Powershell is the only option.

After my first nifty script I wanted to test it. Tricky, no unit-test framework by default. So I stumbled in my search upon Pester. After a download (.zip) and some tweaking it's running! Looks great, needs some work, but it will do the job, go check it out: https://github.com/pester/Pester

Cmd & Bash

I don't have much text here, just a link dump for today:

The art of command line:
https://github.com/jlevy/the-art-of-command-line/blob/master/README.md

Bash strict:
http://redsymbol.net/articles/unofficial-bash-strict-mode/

RESTful essay

I never lost my interested in REST, I even more love how easy people can do it wrong. I'm dumping the link to this essay while reading it. 

In my definition, a real-world RESTful API is an API that provides answers to questions that you won’t find in introductory texts, but that inevitably surface in the real world, such as whether or not resources should be described formally, how to create useful and automatic command-line interfaces, how to do polling, asynchronous and other non-standard types of requests, and how to deal with operations that have no good RESTful mapping.

 https://restful-api-design.readthedocs.org/en/latest/intro.html

Microservice Architecture

Great article by Martin Fowler about the microservices architecture model.


Most application development efforts that we see use a project model: where the aim is to deliver some piece of software which is then considered to be completed. On completion the software is handed over to a maintenance organization and the project team that built it is disbanded.
Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon's notion of "you build, you run it" where a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production and increases contact with their users, as they have to take on at least some of the support burden.



Source: http://martinfowler.com/articles/microservices.html