{"id":25021,"date":"2015-12-07T10:54:10","date_gmt":"2015-12-07T08:54:10","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=25021"},"modified":"2019-01-24T12:11:39","modified_gmt":"2019-01-24T10:11:39","slug":"infrastructure-update-github-bitbucket-hipchat-teamworkpm-and-redmine","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2015\/12\/07\/infrastructure-update-github-bitbucket-hipchat-teamworkpm-and-redmine\/","title":{"rendered":"Infrastructure update : GitHub, BitBucket, HipChat, TeamworkPM and Redmine"},"content":{"rendered":"\n

It’s been a while since I posted an update on our infrastructure tools, so here goes one.  (I know, ideally, it should be on our company’s blog<\/a>, but we haven’t finished that part of the site yet).<\/p>\n

<\/p>\n

First things first – migration from GitHub<\/a> to BitBucket<\/a><\/strong>.  I have said many times that I love GitHub dearly.  And I do.  But it gets expensive pretty fast for the type of company that we are running.  GitHub subscription price is based around the number of private repositories.  Of which we have plenty as we are dealing with client’s projects mostly.  BitBucket subscription strategy is around the team size.  We have a small team and it probably won’t grow significantly in any distant future.  So where we are spending $100 a month on GitHub, and hitting a limit, a $10 per month BitBucket subscription will do for a long time.<\/p>\n

Gladly, with git being distributed and decentralized, migrating from one to another is super easy.  All you have to do is this:<\/p>\n

\n# Remove GitHub remote\ngit remote remove origin\n\n# Add BitBucket origin\ngit remote add origin git@bitbucket.com...\n\n# Update remotes\ngit remote update\n<\/pre>\n
And just to be clear, we are not moving away from GitHub completely.  We are only moving our private repositories over.  All our Open Source repositories will remain at GitHub, as it provides a larger exposure.  And also, we are keeping private repositories for projects where we work with clients’ developer teams, as GitHub seems to be the standard de facto.<\/p>\n
We’ve finished the migration last week and now we are on a $10 BitBucket subscription and $25 GitHub subscription, getting the best of both worlds.<\/p>\n
In terms of functionality, both services offer pretty much the same tools – git repositories, code browsers and review tools, pull requests, API and web hooks, etc.<\/p>\n
GitHub offers a handy feature called “Releases<\/a>“, which extends the functionality of git tags into something more useful – release notes and attached files (like built binaries).  BitBucket doesn’t have it yet, but it’s been requested<\/a> and a lot of people voted for, so there is hope.<\/p>\n
Also, GitHub seems to work a bit faster – BitBucket sometimes gets a bit clunky when your push to it or when you create a Pull Request.<\/p>\n
But BitBucket has a neat Approve button, which works much like Facebooks’ Like.  Instead of all those :+1: and me too comments, one just clicks Approve and BitBucket shows the list of people who approved the pull request.  Oh, and you can also ping people by assigning them to be the reviewers.  So if you want somebody in particular to look at your changes, there is an interface for it, rather than a free form @-mentions.  Which also work by the way.<\/p>\n
For us, the most difficult part of this migration was the fact that we had automated deployment logic built around GitHub actions.  So, every time a pull request was merged into a master branch, we’d automatically deploy the branch to the test server (using GitHub web hooks).  And every time a release was created, it would get automatically deployed to the live server.<\/p>\n
BitBucket provides similar web hooks, but without releases, which we could replace with tags.  But that would mean that we had to support two different deployment scenarios, which sounded like too much.  Also, there were a few issues related to that logic in the first place.  For example:<\/p>\n