freistilbox Blog

Newer articles « Page 8 of 17 » Older articles

Introducing branch-based deployment

When we launched our Managed Hosting service back in 2010, we quickly found that using Git for application deployment was a bit of a challenge for our customers. At that time, distributed version control systems just weren’t widely used yet and many people had no experience with Git whatsoever when they started hosting on freistilbox. So we did our best to keep Git usage as simple as possible.

This is the reason that up until now our deployment system only used the “master” branch of the website instance repository. While you could use any branch in your local development repository to work on your web application, finally the code had to be pushed to the “master” branch on the hosting platform side. If you use multiple website instances for staging and testing you’d push to multiple remote repositories but it would always be to their “master” branches.

Over time, our customers got more proficient with Git and started to adopt multi-branch development approaches such as “Git Flow”. With their Git skills growing, more and more customers started asking for a more symmetrical deployment concept. They’d expect that their “master” branch would go to the production website’s “master” branch, “staging” should go to the staging website’s “staging” branch and so on.

We’re happy to report that finally, multi-branch deployment is here. From now on, you can choose the branch from which each website instance will deploy code.

At the moment, you’ll still have to push to a separate repository for each website instance. But don’t worry, deployment to different website instances from a single central repository will come eventually, so please bear with us.

Until then, you can set up your working repository like this to make things as easy as possible:

git config remote.production.url <production repo URL>
git config branch.master.remote production
git config remote.staging.url <staging repo URL>
git config branch.staging.remote staging

With these settings, a simple git push from the “master” branch will upload your changes to the production instance and a push from “staging” will automatically go to the staging instance.

Are you already excited to test the new branch deployment? Simply send us a support request and let us know the site ID of your website and which branch you’d like us to assign to it.

We hope that this change will make your daily development work a little bit easier. Drop us a quick tweet to @freistilbox to let us know if it does!

freistilbox and data protection

Coinciding with the opening keynote of their CTO Dries Buytaert at DrupalCon Barcelona, Acquia today announced the expansion of their European business. In their PR statement, Acquia claims:

“With data centres now located in Germany, Ireland, and eight other regions around the globe, Acquia is the only Drupal platform service provider to offer pan-European support for high availability sites that accomodates EU data sovereignity requirements.”

We beg to differ.

Since 2010, we’ve been specialising in Drupal and WordPress hosting focused on high performance and availability; first under the “DrupalCONCEPT” brand and, starting in 2012, with our Managed Hosting Platform freistilbox. As an EU-based business, freistil IT has been compliant with EU data sovereignity requirements for over five years now. The data centres hosting our physical IT infrastructure are not only based in Germany but, equally important, also owned and operated by a German company.

On top of fully accomodating EU data sovereignity requirements, freistilbox is compliant with the German “Bundesdatenschutzgesetz” (BDSG) which is widely regarded as the strongest data protection legislation in Europe. German businesses that process client information protected by the BDSG are required to sign a “Vertrag zur Auftragsdatenverarbeitung”, a contract for the commissioned processing of data in which the hosting provider guarantees that both their technical infrastructure and their IT processes meet the strict requirements of the BDSG. The fact that we do has won us the trust of many privacy-conscious customers, for example the Federation of German Consumer Organisations and Doctors without Borders.

In conclusion, while we happily welcome Acquia’s initiative to strengthen the high-quality Drupal hosting market in Europe, we’d like to set the record straight that they’re certainly not the only provider of high-quality Drupal hosting accomodating EU data protection requirements, much less the first.

If you’d like to learn more about what freistilbox can do for you in terms of excellent website performance, high availability and data protection, shoot us a tweet or an email!

Launching our new documentation site

In a strange kind of tradition, we’re launching our new website for the freistilbox user documentation today. We’ve copied all articles over from our Zendesk Help Center (and will remove them there soon in order to avoid confusion). We’ve also used this opportunity to update and improve many of the articles and FAQ entries.

The motivation behind starting a new documentation website was threefold:

  • Efficient content maintenance
  • Fast and effective navigation
  • Extensibility

Efficient content maintenance

As every developer knows, documentation is likely to be treated subordinate to implementation. Especially in a small team such as ours, there’s always work waiting either to improve existing or to build new feautures. In this environment, documenting how these features work or how to use them most effectively is often postponed to when customers actually ask about them in a support request. That’s not the quality of user experience we’re aiming at.

Additionally, maintaining content on a web-based system like the Zendesk Help Center is not the most efficient process when you’re used to writing in your finely optimised text editor of choice. That’s why we’ve been creating our documentation articles in Markdown text files stored in a Git repository for a long while now. On the one hand, this made the actual writing convenient and provided us with a change history for every article. On the other hand, publishing a new or modified article meant that we had to first convert it to HTML, then copy and paste it into the web form and then add additional metadata like tags/labels. The prospect of this tedious manual workflow didn’t exactly invite to make changes, so there always was the temptation of making changes directly on the website – and losing them again with the next update done correctly from the stale Git repository version.

Our new freistilbox documentation website is built with the Middleman static site generator. As until now, we write articles in Markdown and commit all changes to Git. But now, we can publish changes simply by making a git push to the central repository on Github. This push then triggers a CI process which runs a number of tests and (if they were successful), publishes the generated HTML files to Amazon S3 where the website lives.

Yes, we actually run tests on our documentation. At the moment, they only check that our source files adhere to a common Markdown style guide. In the future, there could also be tests for bad writing style such repeated words or overlong sentences.

Our new content publishing workflow will enable us to extend and improve our user documentation with the least effort.

Fast and effective navigation

We felt that using the Zendesk Help Center not only was less efficient for writing content, it also didn’t provide the best user experience to our customers. Finding the right article quickly is essential when you’ve got a question or issue and you’d like to check the available documentation before contacting technical support.

That’s why we’ve added a powerful search function to our new docs site that offers auto-completion and starts showing search results even while you’re typing. Behind the scenes, we’ll also get statistics that’ll help us improve our documentation based on actual search behaviour.

At the bottom of each page, you’ll also find a list of related articles that touch the same topics as the article you’re currently reading.

These improvements will help you find relevant content faster than before. We also hope they’ll reduce the number of support requests so that our engineers can spend their time on more demanding issues.

Extensibility

Search is just one example of how we wanted to make our documentation website as extensible as possible. This requires having full control over its inner workings, which we can’t get by using a third party solution.

Another small example is the link at the bottom of each page that actually allows editing the article in true open source fashion. Since we manage the content in an open repository on Github, everyone who’d like to make improvements to an article can fork the repository, make the necessary changes and send us a pull request. Simply click on the edit link and send us your suggestions!

Over the coming weeks, we’re going to add more features and, most importantly, more documentation that will help you using freistilbox better. If you have any feedback for us on the new website, write us an email or ping @freistilbox on Twitter!

Palasthotel rocks the Rolling Stone Magazine relaunch

As Palasthotel CEO Benjamin Birkenhake announced on their company blog, the web agency based in Bielefeld and Berlin recently finished the relaunch of the German Rolling Stone Magazine.

Rolling Stone Magazine on freistilbox

The result of their work is, and I’m really not exaggerating, awesome. Not only did Palasthotel give the website a fresh design, they also did great development work behind the scenes:

  • 130.000 articles needed to be migrated from Escenic to WordPress. Inspired by Drupal’s Migrate module, Palasthotel developed a WordPress migration framework which they’re going to make Open Source.
  • The site uses 79 plugins, 69 of which were developed in-house.
  • Homepage and landing pages were built with PalastHotel’s plugin Grid.
  • Not only is the website responsive but it also uses responsive images technology that loads images only on demand and in the right resolution.
  • For maximum search speed, Palasthotel developed their own interface plugin for Apache Solr (soon to be published, too).
  • In order to simplify collaboration between three editorial teams, Palasthotel built a solution for sharing image galleries between separate WordPress setups.
  • The site uses 8 custom post types for artists, concerts, festivals etc. For connecting these post types, Palasthotel developed a Post Relationships plugin (which they’re going to publish as well).
  • Their new Postqueue plugin allows creating hand-picked content lists, just like the Nodequeue module in Drupal.
  • And as if this list wasn’t impressive enough already, Palasthotel built and integrated Octavius into the site, their own real-time click tracking service.

Shortly after the relaunch, Ben teamed up with our Chief Uptime Officer Markus for a session at WordCamp Cologne where they presented how our teams cooperate to run High Load Websites reliably, with the Rolling Stone Magazine being only one example.

Congratulations to our friends at Palasthotel for a job well done!

freistilbox now supports syslog logging

In Drupal 7, database logging via the “dblog” module is enabled by default. On high-traffic websites, this can become a problem. When Drupal generates lots of log entries, they can cause significant write load on the database and fill it up quickly. We’ve seen many database backups take longer than an hour because the “watchdog” table was multiple Gigabytes big, and more than one website database bog down under log write load.

The best solution is of course to to fix all PHP notices and warnings to reduce logging overhead. But you’ll still want to have a way of preserving important events in order to analyse them if the need arises. With the “syslog” module, there’s a better alternative to “dblog” and we’ve recently added syslog support to freistilbox. All log entries will simply be written to a log file in your website’s “logs” directory.

If you use our pre-built configuration snippets (and you should), all you need to do is to enable the “syslog” module. Our configuration snippet already comes with all the right module settings. And don’t forget to disable the “dblog” module!

Newer articles « Page 8 of 17 » Older articles