php

I’m a huge advocate of CI and one service in particular called Travis-Ci. Travis-CI runs a continuous integration platform for both open source and commercial products. In a nutshell: Travis-CI listens for a commit to a Github repository and runs your test suite. Simple as that, no Jenkins required. At Imagine Easy we happily take advantage of both. :) So what’s wrong? For some reason, every other open source project (and probably a lot of closed source projects), use Travis-CI wrong in a way, that it will eventually break your builds....

At EasyBib, we’re heavy users of composer and AWS OpsWorks. Since we recently moved a lot of our applications to a continuous deployment model, the benefits of speeding up the deployment process (~4-5 minutes) became more obvious. Composer install Whenever we run composer install, there are a lot of rount-trips between the server, our satis and Github (or Amazon S3). One of my first ideas was to to get around a continous reinstall by symlinking the vendor directory between releases....

Last week I blogged some Vagrant tips and pretty much jinxed the run I had in the past months. Here’s how: I decided to upgrade to Vagrant 1.1, which broke bento: the current bento master is incompatible with Vagrant 1.1. But selecting the right rbenv env and installing the latest available Vagrant gem (inside the rbenv environment) fixed it. My base box build, but for some reason, the guest addition setup broke and while it worked on Mac OSX, it broke the image completely on Ubuntu....

At the last meetup of the Berlin PHP Usergroup, Christoph gave a talk about Vagrant. Good enough of a reason to write down or re-cap some things I’ve learned with or about Vagrant over the last two years. Base boxes There are lots of base boxes available, but don’t be tempted to rely on them (e.g. via config.vm.box_url). Vagrantbox.es doesn’t actually mirror images and that is a huge pain. Available base boxes tend to be outdated....

Testing is important — most people understand that by now. A lot of people write tests for their open source code already, but in-house testing is still hard. For example, many of us had an encounter with Jenkins: it runs well to a point where it becomes harder to maintain the Jenkins than it is to write tests. Another obstacle is test setup and environments: When I write and run tests, there is sometimes only so much I can do to mock and avoid actual calls to my storage backend....