Monthly report for February 2018
Project Management
This month I had to set up a couple of tools to help the team with project and resources management. Some tools were already made available to me, so I tried to make good use of them:
- Taiga, a project management platform;
- a random wiki platform I can’t remember the name;
- GitLab for the code issues.
After trying to tie every tools altogether, it all ended in a massive failure, which made me consider using another combination of tools.
GitLab is fine and wasn’t a part of the problem. I’ve used it for every project I’ve been doing for the last two years, and it has integrations with pretty much every other service. The real problem was the project management tool.
One constraint about the choice of the tool is that it had to be self hosted. We are very concerned about data ownership, and we don’t want to blindly host everything on any third-party service. So I regretfuly had to remove all the software as a service kind of tools from my list.
I’ve had the opportunity to work with Atlassian products around 2010, especially Jira. The impression that I had kept was that it was a very expensive and complicated tool to setup, but also that it wasn’t getting in the way of my daily work. This is a very underrated criteria when it comes to choosing the right tool for the right task, as these days developers unfortunately tend to choose a tool depending on its hype.
The fact is I was wrong concerning the price of the software. Yes you have to pay for it, but it isn’t that expensive, especially if you has ten or less collaborators who will use it.
To get a good picture of Jira, I decided to set up a Vagrant box and use the standalone evaluation version of Jira. After a couple of installs, my environment was up and running, and I spent the following days trying to figure if this was the good tool or not. Let this be clear: It’s a complicated beast to tame, and one can easily lost themselves in the infinite number of options at every level of the software. However, I tried to not dive into useless configuration and went directly for the project management stuff.
Creating a project from scratch and populating it is a daunting task, but it’s made easy since there are a few projects with sample data to play around. I toyed with the sample Scrum and Kanban projects, and came to the conclusion that Jira was a good tool for the job: It still doesn’t get in my way and works like a charm out of the box.
There might be other tools doing some things better than others, but I didn’t have the time to do a complete evaluation of the gazillion project management tools.
Software Deployment
After I had played with Jira on a Vagrant box, I had to deploy it on our servers, and this is how I started playing with Ansible. I didn’t know much about it, but since I’m pretty familiar with configuration management systems –I used SaltStack for a couple of years–, I felt at home pretty quickly.
Why not use SaltStack eh? Well, the whole IT has recently moved from Puppet to Ansible, so I didn’t even bother to try using something else hehe.
Ansible is agent-less, making it dead easy to get it running, it has a pretty solid documentation, and also integrates perfectly with Vagrant. After getting started, I was able to write the complete installation process as a playbook –the Ansible way to describe rules– in a decent way within a couple of hours.
Now I could compare these tools, but I don’t really manage that many machines anymore to have a relevant opinion. I’d say Ansible fulfills my current needs and is really faster to set up, so I’ll stick to it for the time being. If you’re interested in a thorough comparison between SaltStack and Ansible, Anthony Shaw wrote a very insightful one in 2017. His analysis is perfectly neutral and helps understanding these tools. If you’re wondering which one you should choose, that post can be a good place to start.
Learning
I’ve kept doing the Unity Udemy course a bit, and I made it to the item 32… of 332. Way to go!