http://www.go.cd/2014/02/25/go-moving-to-open-source.html ThoughtWorks have been industry acknowledged experts in everything related to the practices of Continuous Integration and Delivery throughout the last decade. They were the creators of CruiseControl which was a de-facto standard tool for CI before all the new tools arrived. Neverthless their own commercial Conitnous Delivery platform named ‘Go’ has never come close to the popularity of even Bamboo or TeamCity ( not to mention Jenkins ). Two days ago they announced they are making Go open-source, obviously as an attempt to increase market share. I gave GO a test-drive a couple of years ago and it seemed like a good tool back then. Now it’s open-source I’ll definitely want to look at it again. I promise to update on my impressons.

Happened today after we relocated a staging environment machine to DMZ. >sudo service mysql start start: Job failed to start. Solution: Mysql has a bind address recorded in it’s configuration file: /etc/mysql/my.cnf bind-address    =    <your.machine.ip> Change the value to your new ip and start mysql. Should work like charm.

Jenkins git-scm plugin provides support for various git repo browser applications, but the wonderful gitlist isn’t one of them… Still I found you can fool Jenkins into using gitlist as your repository browser. (We’ve been using gitlist on one of the ALM environments I manage and gitLab on another one. At some stage I noticed that gitLab‘s commit url is build exactly the same as a commit url in gitlist  : <gitlist_url>/<repo-name>.git/commit/<commit_hash> vs. <gitlab_url>/<repo_name(without .git extension)>/commit/<commit_hash>. Actually what jenkins git plugin does when constructing the repository browser link for gitlab is add the ‘commit/<commit_hash>’ on top of gitlab project url. And it works perfectly fine for gitlist too!) To use gitlist as your git repo browser in Jenkins: in git plugin define the following: Repository browser : gitlab URL: <your gitlist url (repo name with .git)> (eg: http://gitserver/gitlist/myRepo.git) Version: 5.4 Now for every commit in the changes list on build…

Read more

Someone asked at one of the forums if the DevOps hype is justified – after all “it’s something we’ve been doing for the last 20 years”… It’s a good question and here’s what I have to say: DevOps isn’t new, but the hype around it is all about the ever-growing amount and speed of change in the development process. We’ve seen large shifts in development methodologies and release strategies over the last 5-10 years – towards shorter cycles, continuous delivery, automated testing, etc. New tools and practices have been established to deal with these new requirements and organizations now clearly see the competitive advantage they provide. So yes, the discipline itself isn’t new, but it’s role in the software manufacturing process is becoming more visible and acknowledged than ever. That’s what the hype is about. //

In my overview of build automation benefits I already stated that it leads to “Less job burnout due to routine tasks”. That’s another way to say – automation is good for us lazy folks! 🙂 Well, I don’t know about you, but I’m lazy. Especially when it comes to long repetitive tasks with a lot of small steps that are easy to forget. Like closing a release baseline or cleaning my apartment. Alas, we can’t automate the apartment cleaning (as yet), but we can, and should be lazy about SDLC tasks. So how do you go about this?  Well, first of all – get out  these annoying checklists with all the steps needed to close that baseline, prepare that installation kit, merge that branch into the main stream, etc. Don’t  have the checklists? It’s all in your head?!  Well, you’ll have to write it down now – this will be…

Read more

55/55