Posts Tagged ‘GitHub’


Sprint efficiently with GitHub

by Jon Sharratt

As with everything we do here at Red Badger we try and iterate and improve each of our disciplines during an application’s or project’s life cycle. One of the items that we have been exploring is the use of GitHub and what it can bring to the table in regards to agile. Not only this, a view that in today’s world being able to iterate faster and being able to react to feedback from customers and building features as productively as possible whilst maintaining quality is key.  

There is a fantastic presentation from Zach Holman from GitHub who explains how they use GitHub to build GitHub ( It really opens the eyes to the fact that simple tools with no more and no less = happier developers and more effective development.

So with this mantra we decided to switch to try out and only use GitHub tooling for user stories, issues and managing the sprints. During the process of writing this blog post GitHub have announced the way that in which the team works aptly named GitFlow allows everyone to follow the process via the GitHub website.  

Having tried out this process the team and I agree that it is a satisfying and effective way of working especially when applied to agile methodologies.


It is important to note that we follow a branching model of the ever popular If you haven’t read this article and are working with git as version control I would highly recommend giving it a read.

Within your development team at the start of the project just getting your team together and making sure the team understands this before work begins it will 100% give you a smoother application development cycle. To make this process even easier there are git extensions to help you out at

Next we need to explain and break down the components in relation to GitHub tools and how we use them to relate to agile terms:


Within GitHub we would create milestones that represent the sprints and the current sprint we were working through.

User Stories

Within GitHub we would then create a branch that relates to each user story. For example a story/statistics branch for a user story related to statistics development within the application.

Reviews / Collaboration

At Red Badger we also strive to bounce off each other for ideas and improvement on code we produce. For that very reason once a user story is ready for the team to review and collaborate we submit a pull request to the develop branch. Once everyone is happy it is merged and the pull request is closed.

One area which was not explored which in a future project I think would also be great is to use the ability for designers to contribute to an empty pull request (which you can’t do in GitHub as it stands). This way developers can create user stories (pull requests) and collaborate all in one place (it is worth noting emails are supported within GitHub discussions, keeping designers in familiar territory when collaborating around a user story).


Bugs are always going to happen so we used the standard issue features within GitHub provides us with the most effective way of keeping a developer’s workflow focussed on the sprint whilst also allowing bugs to be assigned accordingly.  We gave access to our project manager who can also assign them to a realistic milestone for them to be resolved.

You really don’t need over engineered complicated bug tracking software.  GitHub have the right ethos in my view when it comes to the effective yet simple features they deliver to manage issues / bugs.

The upshot of using these tools in this manner on the project allows us to manage releases effectively within the team with every little disruption. Especially having this layer on top of your standard build tools such as Travis CI  that gives you instant feedback and continuous delivery directly integrated with GitHub.

The only one downside that isn’t cracked is that that traditional burn down charts for project managers are not integrated within the whole process. If we can solve the backlog planning and estimation with integration to GitHub we are on to the perfect solution for a self managed team without duplicated laborious project management “chores” each day.

It is all about keeping developers in the zone, doing what we love to do best.


Meet Joe – The New Badger Intern

by Joe Stanton

After joining Red Badger a couple of weeks ago, I thought I should share who I am, and some of the things I’ll be working on in the near future. I’m a student at King’s College London studying Computer Science and I applied to join Red Badger a couple of months ago to gain some experience of developing real software in a company which do things the right way. Mugshot

After a friendly email exchange, I was invited to take part in a programming challenge to whittle down the number of applicants, and give the real developers (now my mentors) a feel for my experience. With a background in C#.NET and web development, combined with a passion for cutting edge technology, Red Badger are a natural fit for my current skillset and how I’d like to develop my skills in future.

My first couple of weeks have so far introduced me to how development at Red Badger works; Agile and highly creative with a strong emphasis on User Experience and Design,development starts with writing spec’s to ensure code quality, attention to detail is very important. I have also spent some time getting acquainted with the tools Red Badger use during collaborative development, such as GitHub for source control and TeamCity for Continuous Integration with integrated Unit Testing.

My main project initially will be Birdsong, Red Badger’s fantastic WP7 twitter client. This should please many of the current users, as it will be receiving a lot of care and attention over the coming weeks after a period of neglect! There are a few features in the pipeline, including support for Trending Topics (both local and global), ReadItLater/Instapaper support for tweeted links and large-scale improvements to the push service.

If you are a current user of Birdsong and have a feature request, now would be a great time to submit it to our support site at If you aren’t a current user and you own a Windows Phone, what are you waiting for!

I look forward to learning lots and adding real value to the project and any others I may be involved in in the future!


TeamCity, GitHub and SSH Keys

by David Wynne

If you’re a Windows based user of GitHub and using TortoiseGit then it’s highly likely you’ve used PuTTYGen to generate the SSH key you’re using with GitHub and why not – it works fine.  That is until you want to start using TeamCity with GitHub.

If you try to configure your VCS root in TeamCity using the bundled Git plug-in, with a private key generated with PuTTYGen, you’ll likely get the following error: Connection failed!  Repository ‘’: Unable to load identity file: C:\whatever\YourPrivateKey.ppk (passphrase protected)

TeamCity Connection Failed

We spent a while messing around with the different authentication methods available in the TeamCity – trying to configure default .ssh keys for the logged on user, adding SSH config files and nothing worked.

Eventually we re-generated our SSH key using Git Bash, instead of PuTTYGen (as detailed here) and suddenly – Connection successful!

I’ve since discovered that you can get the same result using PuTTYGen, but you have to export your key as a OpenSSH key: Load your existing private key – File/Load private key (enter your passphrase).  Export to OpenSSH – Conversions/Export OpenSSH key.  Use the resulting key as the private key you give to TeamCity.