October 31, 2017

Introduction

Let's imagine that you (or your customer) have a great idea of a project. You are working on it locally alone. Later you build a team and you need to share code among teammates and show an intermediate result to a client. You are not a DevOps - you don’t know each teeny-tiny technical detail of server configuration. More than that - you don’t want to know. You like just to code! And, of course, you don’t want to hire a special person to do it. What to do? You are searching for a shared hosting. And what you can see - almost all shared hostings provide you with an ugly cPanel interface and force you to upload code via SFTP. SFTP? Are you kidding me? It is not the year 2000! You need at least: an SSH access, Git, and Drush. You’d like to have a simple and convenient administration panel which allows you to do some minimal server or PHP configuration. You’d like to have isolated environments and technical domains. And of course, you’d like to keep it simple.

Sounds like a story of your life? If the answer is ‘yes’ - this article is for you.

In this and the following articles, we will tell you about popular cloud hostings: Pantheon and Acquia Cloud. We’ll observe advantages and disadvantages based on our development experience.

Let's talk about Patheon first. Pantheon is a Website Management Platform. It allows you to work with Drupal and WordPress projects.

Start of work with Pantheon

You can start a new Drupal 7, Drupal 8 or Wordpress project in a few clicks. You just have to enter a project name. That’s all: Pantheon cloud will do all the things for you.

Also, you can migrate an existing website to Patheon following these steps:

  • create a website archive using the drush ard command. This command will generate an import-ready archive of your website code and your DB. Please note that the maximum archive size is limited to 500MB
  • upload the archive with the Terminus tool or a direct URL
  • upload static files via SSH or SFTP

A manual migration option is also available. If you are familiar with SSH and Linux CLI - this option is for you. If you choose the manual migration, Pantheon will create an empty project for you. You have to upload a codebase, the DB, and the static files manually via SSH and using Git. See the manual here.

Ok, you created a new project or migrated an existing one and now you have an access to the Pantheon dashboard.

Pantheon Dashboard

Pantheon Dashboard

The Pantheon dashboard is really nice and well-designed. In comparison to standard cPanel - it has an intuitive UI. The Pantheon dashboard allows you to perform different actions on a project very easy. You can:

  • Choose the connection mode (Git or SFTP)
  • Move a database and static files between environments, import and export the DB and the static files
  • Add and manage domains
  • Add HTTPS (available only for a pro account and higher)
  • Manage backups and configure scheduled backups
  • Protect your environments with simple HTTP-auth
  • Update Drupal Core
  • Deploy code changes or merge multidev branches
  • Enable some add-on’s

More than that you can:

  • Review the commits’ history
  • See error logs
  • See a status report and the best practice recommendations

All these features are really useful and help with some route tasks of managing your project and environments.

Isolated environments

Out of box Pantheon provides 3 environments: dev, test, and prod. Pantheon creates technical domains for each environment in the following format: <environment>-<site name>.pantheonsite.io (of course, you can attach your own domain for each environment). This is a very cool feature which isn’t  used by the most of the shared hostings. It allows you to share an intermediate result with a client and demonstrate new website features.

Let’s assume that the dev environment is your working environment. Changes are available right after you push commit. You don't need to pull changes - Patheon will pull everything automatically.

The test environment can be very close to the prod environment. You deploy some ready features into this environment to test it before going live.

The live environment will include all tested features.

Of course, a way of using these environments is up to you.

Starting with this, let's talk about development experience and a workflow.

Git workflow and Pantheon multidev

There are two types of workflow provided by Pantheon: standard and multidev.

Standard workflow:

Standard Pantheon workflow

You are working in the master branch. Of course, you or your teammates can create a branch as you used to, but Patheon doesn’t see any of them and you can’t switch an environment to use any of these branches.

Pantheon provides the autopull feature so that you shouldn’t pull your commits: it will be done automatically out of box. All your commits go to the ‘dev’ environment.

To deploy changes into the test environment, you have to open this test environment and click “deploy” or do it with Terminus tool.

So, if you need some changes to be deployed to live, they should be deployed to the test environment at first and then to the live.

It sounds like a good flow: it means that you are testing all your features before they go live. But it is just on the one hand.

On the other hand, let's imagine that you are not working alone on a project. You push a feature to the dev, your teammate pushes another feature too. You are working on the same branch. At the particular moment, you have to deploy changes to the test or to the live. As far as you are working on the same branch, your teammates’ changes will be deployed too. But you only need your changes. In this case, you have to revert teammate’s changes, deploy yours, and then revert teammate’s changes on the dev again. Not a very good experience, do you agree?

It can be solved with enabling the multidev feature.

Enabling the Pantheon multidev feature

The multidev workflow allows to fork the entire stack (code and content), work independently, then merge code changes back into the master. Each forked branch will have its own separate development environment, including a database, files, and a separate Git branch. Now, you can create a separate environment for every task or feature on your project and work independently.

It is more flexible, isn’t it?

Yes, but I still need more flexibility. And it is the only thing I don’t like in Pantheon.

I don’t have a full control of my repo. Of course, the idea of the ‘dev -> test -> live’ flow is the right idea. But sometimes I want to have separate Git branches for different environments. There is no way to have it in Patheon.

Another bad thing - hotfixes.

What if I need to push a fix very fast to live? Should I still forward my commit through the ‘dev-test-live’ deployment chain? What if there are some outstanding commits in the dev? They will be deployed too and, of course, I need to avoid it. How to solve it?

Pantheon uses the tags system for deployment. So, if you deploy something to the test,  pantheon_test_<id> tag will be created. The same for the live environment.

So, to create a hotfix to live you have to:

  • get the highest live tag, use the following command: git tag | grep pantheon_live_ | sort -k1.15n | tail -1
  • let’s assume that the highest tag is pantheon_live_10. Checkout to it: git checkout pantheon_live_10
  • create a new Git branch: git checkout -b hotfix
  • implement your hot changes in code
  • generate a new tag. Our last tag number was 10. So a new tag number should be 11. git tag -a pantheon_live_11 -m "Deploying my hotfix"
  • push it git push origin pantheon_live_11

After that, the new live tag will be automatically deployed to live. It sounds like a hack - but it is the only way to create a hotfix in Pantheon.

As I said, this is the only bad thing in Pantheon from my point of view.

Let’s examine other Pantheon cool features.

Additional features

  • Upstream updates. Pantheon team keeps track of Drupal Core updates. Once a new Drupal version is released, updates will be available on Pantheon almost immediately. Please, note that you can apply core updates only using a dashboard or using Terminus. You will not be able to update the core using the drush up drupal command. This is because Pantheon does some modifications with Drupal Core. That's why they prepare updates individually for each new version.
  • Free HTTPS via Let's Encrypt service
  • Varnish caching
  • Global CDN
  • Pantheon allows adding the Solr search server and the Redis cache server
  • Pantheon allows attaching ‘new relic’ monitoring tools

Terminus

Another important feature is a command line interface which provides advanced interaction with the Pantheon cloud platform. Terminus enables you to do almost everything in a terminal that you can do in the dashboard, and much more:

  • Create a new website (project)
  • Create and delete the multidev environment
  • Clone one environment to another
  • Check for and apply upstream updates
  • Deploy code from one environment to another
  • Create your own command and extensions
  • ….

If you are familiar with the Linux terminal - it is a good alternative to a UI dashboard.

Conclusion

Cloud hosting platforms are the next level of hosting solutions. In this article, you learned about the popular platform called Pantheon and how easy you can deploy the development-ready environment just in a few clicks. If you are still using an old hosting platform with cPanel - it is a good time to migrate your project to a cloud hosting.

Migrate my site

Cloud hosting

Want to move to a cloud hosting?

You’re just few steps away from the development-ready environment. Contact us to migrate your website.

Was this article helpful? Click to rate: 
Average: 4.7 (7 votes)

You may also like

Complex of reasons Drupal is one of the most powerful CMSs in the...
Introduction If you opened this article, it means that you want to...
Regression testing allows to find bugs caused by the previous...