- Nightly builds that take longer to run
- Daily or weekly deployments to a test environment
- Data validation and backups
- Load tests and tracking performance over time
- Jobs and tasks that aren’t coupled to code changes
Dear BitBucket, can you please dial down your LGBT celebration. Changing your website logo is one thing.
But adding 20+ lines with ANSI codes to the “git push” output and all without warning is way too much. If you don’t believe me, check #bitbucket hashtag on Twitter, and see how many happy customers you have now.
P.S.: keep in mind that this is a paid service too. WTF?
I came across this rather strongly opinionated blog post – GitFlow considered harmful, and I have to say that I mostly agree with it.
In our company, we use a similar approach to the Anti-gitflow, but with even more simplicity. This is one particular thing I like so much about git is that each person, team, or company can pick the workflow that suits them best.
Just to give you a little bit of context, we have a rather small development team (under 10 people), but we do a large number of projects. All our projects are web-based, varying from small and simple websites (static HTML), through more complex WordPress sites (multilingual, e-commerce, etc), to business applications like CRMs. Each project is done by several developers at a time and can later on be passed on to other developers, often much later (another iteration after several month). Each developer is working on a number of projects at a time. And we do very fast-paced development, often deploying multiple versions per day. Given the nature of the projects and the development pace, we don’t ever really rollback. Rollback is just another step (version) forward. And we don’t have long and complex roadmaps in terms of which features will be released in which version. It’s more of a constant review of what’s pending, what needs which resources, and what we can do right now. (It’s far from ideal project management, but it somehow works for us. If you think you can do better, send me your CV or LinkedIn profile, and we’ll talk.)
In our case, we do the following:
- We have one eternal branch, and we call it master.
- The master branch is always stable and deployable. Even though we don’t really deploy it directly.
- Nobody is allowed to commit directly to the master branch. Initially it was just an agreed convention, but because people make mistakes, we now have this rule enforced with the technology. Both BitBucket and GitHub support protected branches. BitBucket, in my opinion, does it much better.
- All new features, fixes, and improvements are developed in separate “feature” branches. Most of these are branched off the master. For large chunks of work, we can create a feature branch, and then introduce incremental changes to it via sub-feature branches, branched off the feature one. This allows for easier code reviews – looking at a smaller set of changes, rather than a giant branch when it’s ready to be merged.
- We do code review on everything. The strongly suggested rule is that at least two other developers review the code before it is merged. But sometimes, this is ignored, because either the changes are small and insignificant (CSS tweaks or content typos), or we are really in a hurry (we’ll review the changes later). But whatever the case is, nobody is allowed to merge their own pull requests. That is set in stone. This guarantees that at least one other person looked at the changes before they were merged in.
- We tag new versions only on the master branch.
- We use semantic versioning for our tags.
- We don’t deploy branches. We deploy tags. This helps with preventing untested/unexpected changes sneaking in between the review of the branch and the deployment.
The above process suits us pretty well.
Here are some exciting news from the BitBucket Pipelines blog: Bitbucket Pipelines now supports building Docker images, and service containers for database testing.
We developed Pipelines to enable teams to test and deploy software faster, using Docker containers to manage their build environment. Now we’re adding advanced Docker support – building Docker images, and Service containers for database testing.
Shields.io provides a large collection of badges that you can use in your project documentation (like README.md over at GitHub or BitBucket), which shows a variety of metrics for the project – latest version, number of downloads, build status, and more. Pretty much anything that you’ve seen used by any project on GitHub is supported (I couldn’t think of a badge that wasn’t).
Now, if only there was a way to insert these things automatically somehow …
BitBucket has implemented one of the most frequently requested features, which was outstanding for more than three years now – creating tags from the source browser (as in BitBucket web interface, rather than from the local repository, using git and then pushing it to remote).
I didn’t see the announcement in the BitBucket Blog, so I thought I’d post it here.
In order to create a new tag, navigate to the Commits page of your repository, then click on the hash of the commit that you want to tag, and then create the new tag from the upper right corner interface as per this screenshot:
It’s not the most obvious place to have this functionality, and the other feature – the equivalent of the GitHub releases – is still missing, but it’s better than having to use the local repository.
Update (January 23, 2017): BitBucket Blog carries the post now.
I’ve been meaning to look into Docker for a long while now. But, as always, time is the issue. In the last couple of days though I’ve been integrating BitBucket Pipelines into our workflow. BitBucket Pipelines is a continuous integration solution, which runs your project tests in a Docker container. So, naturally, I had to get a better idea of how the whole thing works.
“Docker for PHP Developers” article was super useful. Even though it wasn’t immediately applicable to BitBucket Pipelines, as they don’t currently support multiple containers – everything has to run within a single container.
The default BitBucket Pipelines configuration suggests the phpunit/phpunit image. If you want to run PHPUnit tests only, that works fine. But if you want to have a full blown Nginx and MySQL setup for extra bits (UI tests, integration tests, etc), then you might find smartapps/bitbucket-pipelines-php-mysql image much more useful. Here’s the full bitbucket-pipelines.yml file that I’ve ended up with.
A few days ago BitBucket announced the re-worked dashboards, which are now much more focused on the Pull Requests that you’ve created or need to review, rather than lists of repositories that you have access to. I’ve enabled the feature for my team and it looks super awesome!
If you’ve been suffering from being lost in dozens or hundreds of projects and missing out on the Pull Requests activity, check them out. You’d be surprised.
Git 2.9 has been released a few days, bringing in some very useful functionality, such as showing renamed files in git diff and git log, forbidding the merge of two branches that have no common ancestors, configurable path to hooks, and more. All are welcome changes, making the life of a developer easier.
But what I found interesting is how two largest git companies – GitHub and BitBucket – reflect on it. Surely, the new release is important to both, but it’s insightful to see which features each of them looks at first. Have a look: