Hi! I'm Dima Sabanin, Rails developer at Wildbit. I've been working on some cool new Beanstalk features that we'll be releasing today. Let me give you a short guide on what we've added and changed.
Incidents
At Beanstalk we are always striving to make your experience as flawless as possible, to make things "just work", but it's not always possible. Sometimes errors happen, and up until now you had to contact support to do something about it.
Enter Incidents
I've created a system that will report all kinds of different issues that may rise for your account, and give you a way to debug them or notify support.
For instance, in the case if you have a failing repository import - you will know exactly why it failed - maybe you uploaded the wrong file, and now you can resolve the issue by yourself, without waiting for an answer from support.
Another instance is failing Release deployment - these were hard to debug without support before.
Now if Release fails, you will see an error message, complete log information about what went wrong - it will help you setup and debug your Release servers correctly.
Third example where Incidents will come in handy is debugging integrations with third-party services that we offer to all of our customers. Sometimes API's change, authentication tokens get changed or accounts get suspended - whatever the reason - you will know.
I want to add, that Incidents will not replace our support team. We're always eager to help you with any issues, no matter if there are any Incidents involved. Incidents are for those cases when there is a big chance the issue is not on our side, and you want to take care of it yourself to continue with your work faster.
Releases
We've had Releases - automated and manual deployment of your repositories to your own servers - for a year already and yet it's still in Beta. Here's an explanation for this - we weren't happy with the functionality or with the average time it took for Release to get deployed. Until now.
I've replaced a big chunk of Releases code with a simpler and more straightforward system, that works using a different principle. Let me explain. Before now, to deploy a Release we basically made an export of your repository on our server, then connected to your deployment server and just mirrored these two directories. It took a lot of time, because we had no way to know what had changed on your server, and even if you were deploying the change to a single file, we had to compare every single directory of your deployment directory with our local copy.
I must admit that it was my bad decision, back when I was developing the previous version of Releases. I won't defend it now, let's just say we all make bad judgements sometimes :)
Here's how new Releases work. We figure out what is the last revision deployed on your server, and we know what revision you want to deploy. We take all the changesets in between these revisions, and extrapolate exactly what we should update, add and delete from the server. Now you see why it will be much faster than the previous way.
There is one catch though
Subversion is not very bright. It thinks that when you move two directories, you actually delete old one and create new directory. It's more complicated than that, but basically it is true. Because of this, when we collect changesets to deploy on your server, we have to delete directories that were removed/renamed/moved in Subversion repository from your server. This is an important change from the previous Releases, when nothing was ever removed from your server, even if you wanted it to.
We discussed an option where we would only delete files from your server if you enabled a checkbox in your Release configuration, but we decided that it won't work. Just imagine what the deployment on your server would look like, if every source directory for any moved or renamed directory would just be left lying there forever. The tree would turn into a mess very fast. Anyway, we wanted to let everyone know about the change, so if anyone relies on the behavior that Releases do not delete files will have a chance to stop it.
If new Releases cause problems for you or you have some bright ideas on how to solve the situation with moved directories, please contact us. If everything goes fine, in the next few weeks hopefully Beta tag from Releases will go away forever.
Other small, but important stuff
While working on Incidents, I've also put a lot of effort in making daemons that manage background tasks in Beanstalk, such as Releases, Imports, Caching work faster and more reliable. One of the things that was improved is Amazon S3 backups - we had some issues with it, and now they are resolved and we have reliable constant running incremental backups to S3, in addition to our various other backups. Your data is now safer than ever.
We've also had some noticeable hardware and infrastructure improvements, thanks to EngineYard.
Petyo and Ilya also put a lot of hard work into fixing old and new bugs, that were bugging our users, and they have plenty new stuff up their sleeves. Igor Balos, testing superman, made this release stable, and our design gurus Gilbert and Eugene, added style to the UI.
We won't be deploying all the upgrades at once though. Today we will deploy bugfixes, Incidents and Releases. Later this week we'll deploy infrastructure changes such as new slice for our daemons and another GFS storage partition for your repositories.
This turned out to be one lengthy post, but so is this Beanstalk upgrade. We sincerely hope you'll like it.
Please, let us know if you have any issues or comments.