So since I have a decision on how I am going to deploy code (Ansible), and know how I am going to manage that deployment (Rundeck), it is time to look at how we can receive code from the engineers. There are many options out there for source control, and all of them will work, and each have positives and negatives. That and I had a good Christmas and New Years, hence the delay between posts :)
Cost is a big deal long-term, and a lot of the source control systems out there are based on a per-user pricing model. Perforce and BitBucket are good examples of these. BitBucket is one of the best if your team will never go beyond 5 people (it is after all free for teams of 5 or less) and ends up with approx. $1/user/month until you hit 200 people; and Perforce I'm sure will tell your their prices are of course totally understandable for all the features they provide, albeit at a starting cost of $25/user/month cost for less than 20 people.
The alternative pricing model of course is based on distinct sets of code (or repositories as they are usually called). This means you can have a team of one or 10,000 and still only get charged just for the number of repositories you have subscribed to.
My personal favourite in this area is GitHub. Public (and so open source) projects are free, and private repositories (repos) start at $7/month for 5 repos as an individual, or $25/month for 10 repos as an organisation. GitHub has a pretty awesome lineup of capabilities, and has web based, application based and command-line based tools to work with the code.
Yes of course my recommendation (my opinion creates undertones to the above) is GitHub. My personal account is used with a subscription for my personal work, and that same account has been used in quite a few different organisation accounts (even at the same time depending on who I have been working with). GitHub also provides a good two-factor authentication system to help protect my own work as well as any organisations work I'm also attached to.
By using the branching and forking features, individuals or even small groups can work on sections of code and have them pushed up (and hopefully reviewed) into the main master branch before code gets deployed. It's also possible by using forks to protect your 'production' repo within a single account. If your engineering manager can trust his engineers to control production deploys just using pushes into the master branch, a single repo with no forks is of course a method of getting code deployed without the overhead of other repos. Personally I prefer the fork method as it gives a bit of control over who can run the push, and this can also be used to protect your auto-deploy code if you have some.
One of the features of the fork model within GitHub is that if an Organisation or personal account creates a 'private' repo, anybody you give read permissions to and therefore grant them the ability to create a fork of that private repo will also automatically get a private repo for that forked set of code. This isn't obvious at first glance as the working around non-subscribed personal accounts is that all repos will be 'public' - this is only true of repos that are created from scratch - forked repos dance to a different tune, which as an admin of an Organisation with sensitive code, knowing that a fork of our private code will also stay private within an account that isn't a subscriber is a big deal. It's also worth pointing out that when somebody leaves your organisation, any private forks will also be removed from their account (yes, I know they will still have code on their local machine, but thats what a good NDA is for when you have somebody join your organisation!).
So I'm guessing you are asking yourself, why should we care what code system the engineers are using? Well, rightly or wrongly, code repository choice also can dictate which build systems you can use. Personally I was using GitHub before having to worry about a build system, and most of the market leaders in the build world can take stuff from GitHub - after all, its just git with a pretty GUI right? ;)
In my next blog, I'll move into the high level view of the build system, in a similar vein to this post on code repositories....