Live From The Bunker

Sorting ones development team out can be a real pain in the bum! Massively exciting, but as we are taking on even more developers I have spent the last few weeks freaking out that we don't have the right environments/documentation/tools/api's sorted (you can pretty much pick one of those randomly and hear me moan about it at least once a day). So after a lot of reading, setting up, breaking, re-setting up and realising that I could of done it much easier, I have decided to dump everything I have set up here for all the world to see. Just to set the scene, we are a team of 3 full time devs, 4 contractors, and I sit in the middle. Of the team we have 4 working platform (Rails) and 3 working across our content projects (Flash/HTML/XML).

Get it on Github

At the start of this process our project lead and I spent some time working out whether we could move our bug tracking to Github tickets, and although we loved it for it's simplicity it was a bit of a hard sell when we had stakeholders who were used to the rich worlds of Jira and Mantis. I must admit that this was the start of something truly beautiful, Github tickets have about three degrees of variance, they can be labelled, set against milestones, and assigned, which put people off in the first instance. There isn't any fancy time management (which we never really used correctly anyway) there isn't a very detailed roles management where you can create reports and managers and stuff, BUT the three degrees it does off you will work in every scenario (at least every one we have encountered). I could probably write a whole post about how this has raised productivity... soon :P

Embrace Github as a User Credential

Because we are now getting everyone that works on a project into Github, and setting their account against our organisation, and even organising them into subteams within that organisation, we are able to use Githubs Auth API to log our users into our internal systems. Previously we had credentials for this that and the other (and no we would never consider trying to get our central LDAP to do this!) which was a pain to manage, but now we can just use Github accounts to ensure that users are within the right organisation, and even use teams as a way of assigning roles! Bonza!

If you can't Heroku, Dokku...

I love Heroku for getting development projects online and seeing if they float, it is easily the simplest deployment method that I have ever come across, but it has always just been on a free access account. I did contemplate getting us some budget for hardware, but because we already have an active involvement with AWS this seemed a little like overkill on cloud infrastructure. I had come across Dokku on a blog post when it first hit release and could see that it was pretty exciting but after spending a little time with it I was able to create a mini Heroku clone on our own AWS box, fantastic! Now all we need do is add our server as a remote for a git project, and push it up and ouila! It creates a subdomain based on the project name on our testing domain boxes the application up in a Docker package and has so far run first time everytime (pretty unheard of). One issue we had was getting a Postgres database set up that the applications could hook into, there are some Dokku plugins out there but they are a little hit and miss and don't quite have the sheen that Dokku does. Our solution was to not rely on the Docker container to run Postgres, but have a central Postgres DB that any of our applications could connect to. We can just provision credentials for the apps that need it, set the DATABASE_URL env var on the Docker container and boom, works first time. The other nice thing about this is we can do all of the migrations on developer machines without having to rely on connecting directly to the server.

And Encourage Custom Apps

What things like Dokku and Heroku give you is a rapid deploy method and an easy route to your users. For me this is a fundamental change to computing in the last few years which I think has been truly revolutionary. I have developed small applications for custom tasks for as long as I have used a computer, a script to do this, a database to hold that and now I am able to deploy those apps and share them amongst the team. Custom applications are a great replacement to some of the horrors that go on in the modern workplace. Take that spreadsheet you have with forty different sheets in it and formula that dump things into pivot tables and use a fairly precarious set of rules to work out differentials. Take a day or two, stick this in a simple Rails app (just go mental with scaffolds), tweak it a little to make it user friendly and hey presto, you have just started out on a beautiful journey. We did this for our content catologue, and in the process stuck a custom made wiki on the side, and made everything commentable (using Github credentials of course) and it is fantastic (we have built it in 3 days!).

Spend Just Five Minutes Learning Jenkins

With our content project being so reliant on XML, and our platform project being test driven, I don't know why it didn't dawn on me sooner to have Jenkins somewhere. I think it was because I was concerned the learning curve would kick us out of sync a little with our brutal schedule, but if anything the small amount of time we have spent getting this set up has meant we now know exactly what we have to do to consider something signed off. We have been using a content XSD schema that we developed for almost a year now, and have a whole slew of content that has been authored in it. Our documentation states that you can do various things in the content schema (which our authors have utilised) that the schema doesn't actually support... Thankfully the players that render the content do, but if it wasn't for Jenkins running an Ant script that checks each and every piece of our content for schema validation we would have never have known... And maybe one developer might have got the schema and not found that this was possible!

comments powered by Disqus