Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Symfony Blog:
How we Auto-Deploy Documentation Pull Requests with Platform.sh
Sep 10, 2015 @ 12:42:38

On the Symfony blog Ryan Weaver shares a "behind the scenes" look at how the project handles and has automated their documentation generation process with the help of the Platform.sh service.

[Symfony's documentation](https://github.com/symfony/symfony-docs) is an open source project with more than 800 contributors. That’s great! But our goal is to always make it easier to contribute and faster to merge in changes. And today, we’ve started doing something really cool to improve our workflow: integration with [Platform.sh](https://platform.sh).

Platform.sh is a hosting solution that provides out-of-the-box continuous deployment for Symfony, Drupal and any other PHP applications. It extends the concept of a Git branch at the infrastructure level. Basically, this means that it’s easy to deploy every branch and/or Pull Request to its own URL.

He talks about the documentation's format (Sphinx) and how, while it does provide flexibility it also can lead to maintenance issues too. Changes can't be seen immediately and it's difficult to review. Instead they worked up a process where each pull request was automatically deployed to its own unique URL. This reduces both issues they were setting around instant feedback and review problems and provides a better experience for the developer overall.

tagged: integration platformsh documentation request pull symfony continuous deployment

Link: http://symfony.com/blog/how-we-auto-deploy-documentation-pull-requests-with-platform-sh

Piotr Pasich:
Putting all pieces together and shipping with Codeship (Continuous Deployment – part I
Aug 18, 2015 @ 12:45:01

Piotr Pasich continues his series covering the integration of Docker, Elastic Beanstalk and Codeship to create a workflow for shipping and releasing code. In the first two parts of the series he set up most of the technology involved and hooked some of it together. In this latest article he finishes the process, connecting CodeShip with GitHub and your tests.

Today I will walk you through combining all the pieces together and automating the process fully. A continuous integration system will be placed between developer’s environment and final servers. I’ll present how to achieve all of that with Codeship. What make me choose this particular mechanism? The simplicity of setting up, number of additional tools ready to use without installation and finally the fact that it isn’t time consuming.

He shows how to connect CodeShip with your GitHub repository. He shows how to create a new CodeShip project to handle the build complete with a screencast to ensure things are set up as they should be. He includes a bit of "magic" you'll need to do with the CodeShip configuration to get it to work with the Docker setup, but the change is minimal. He also shows you how to set up the execution of your tests and how to see what failed when a build is broken. Finally he shows the process for setting up the deployment to the hosting provider (in this case Digital Ocean) and how to configure your Amazon credentials right in the interface.

tagged: codeship elasticbeanstalk continuous deployment series part3 docker tutorial

Link: http://piotrpasich.com/putting-all-pieces-together-and-shipping-with-codeship-continuous-deployment-part-iii/

Piotr Pasich:
Automated deployment with AWS Elastic Beanstalk (EB) – Part II
Aug 07, 2015 @ 09:14:31

Piotr Pasich has posted the second part of his series showing you how to set up an automated deployment process for an environment that includes an Elastic Beanstalk instance. In this part of the series be builds on the process created in part one and shows the setup and configuration of the Beanstalk instance.

In the previous part we set up a dedicated Symfony application on Docker virtual containers and prepared environments that may be transferred between developers during project cycle. The next step is to prepare the application for pushing into the cloud. There are many options available on the market – Heroku, DigitalOcean and, my favorite, AWS Elastic Beanstalk.

He walks you through the Amazon side of things first, getting the Beanstalk instance set up through the AWS control panel, selected from the AWS list of services. He goes through the options you'll need to configure to get the instance all set up and running including the resources to allocate and instance type (t1.medium is recommended). He then helps set up some of the necessary environment variables for configuration information and a bit of a hack to Symfony that lets you override local parameters with ones coming from the environment. Finally he configures the Beanstalk application and setting it up for automated deployment.

tagged: series part2 elasticbeanstalk aws deployment automated tutorial

Link: http://piotrpasich.com/automated-deployment-with-aws-elastic-beanstalk-eb-part-ii

Full Stack Radio:
14: Taylor Otwell - Building Envoyer, Laravel 5.1 and Learning to Program
Apr 09, 2015 @ 09:18:04

The Full Stack Radio podcast has released their latest episode: Episode #14, "Taylor Otwell - Building Envoyer, Laravel 5.1 and Learning to Program". In this new show host Adam Wathan is joined by Laravel creator and lead developer Taylor Otwell to talk about the framework, the Envoyer deployment tool and development in general.

In this episode, Adam talks to Taylor Otwell, creator of Laravel. Taylor gives an in-depth behind-the-scenes look at how Envoyer is architected, and shares some new tips and tricks he's been using to keep his code simple. They also talk about the decisions behind upcoming changes in Laravel 5.1, how Taylor learned to program, and how he almost became the manager of a retirement home.

You can listen to this latest episode either through the in-page audio player or by downloading the mp3. Be sure to also subscribe to their feed if you enjoy the show.

tagged: fullstackradio podcast taylorotwell laravel envoyer deployment programming ep14

Link: http://fullstackradio.com/episodes/14/

SitePoint PHP Blog:
First Look at Platform.sh – a Development and Deployment SaaS
Mar 23, 2015 @ 11:24:36

In this latest post to the SitePoint PHP blog Chris Ward takes a "first look" at the Platform.sh development and deployment service.

Not so long ago, many of us were satisfied handling deployment of our projects by uploading files via FTP to a web server. [...] The old methods for deploying became unstable, unreliable and (generally) untrusted. [...] So was born a new wave of tools, services and workflows designed to simplify the process of deploying complex web applications, along with a plethora of accompanying commercial services. Generally, they offer an integrated toolset for version control, hosting, performance and security at a competitive price. Platform.sh is a newer player on the market, built by the team at Commerce Guys, who are better known for their Drupal eCommerce solutions.

He talks about some of the requirements for using the service (including Drush, the Drupal command line tool) and how to get started with a new project. He shows how to get the codebase with their CLI tool, pushing SQL data up to the instance, and starting in on some development work. He shows how to configure the modules you want to use and adding some additional content to the data. He also covers some of the other features of Platform.sh including: performance and profiling tools and integration with Redis, Solr and the EntityCache/AuthCache tools.

tagged: platformsh drupal deployment development platform saas introduction

Link: http://www.sitepoint.com/first-look-platform-sh-development-deployment-saas/

Servers for Hackers:
Deployment with Envoy
Feb 11, 2015 @ 13:09:31

The Servers for Hackers site has a new post walking you through the steps to deploy a PHP application with Envoy, the Laravel-based ssh task runner to make automated deployment simpler.

We'll use Laravel's Envoy to deploy a PHP application to a production server. This will make a new release directory, clone the repository into it, run any needed build steps, and then finally swap the new code out with the older code, so that Nginx and PHP-FPM serve the new code.

They walk you through the full setup you'll need to get the deployment working including generating ssh keys, installing Envoy globally and making the first Envoy configuration file. With that in place and working, he enhances it with quite a few more steps including checking out a new version of the repository to a "release" directory, executing Composer to pull in needed libraries and changing the symlink to point the document root and the freshly installed version. He also includes the configuration for the Nginx server to set up a Laravel-based application inside of a Vagrant VM instance.

tagged: envoy deployment laravel tutorial nginx configuration automation

Link: https://serversforhackers.com/deploy-envoy/

Zend Blog:
Continuous Delivery: The Benefits and Barriers of Automation
Feb 10, 2015 @ 12:09:08

On the Zend blog there's a new post that looks at one of the major steps when you start to think about automation in the deployment of your application - continuous delivery.

For many, the process of manually developing and deploying software to production is archaic at best. Even in highly automated software development environments, at least one developer (although often more) typically manages modifications to code and software products, and the ramifications of these modifications can be extensive or unknown. [...] The emerging process for developing and deploying applications of high quality is one that is highly automated, executing continuously, and covers the entire development process, from modifying code through testing to deployment. Automation provides analysis that flags code for improvement and executes full regression tests every time a modification is made.

[...] This process is called continuous delivery, and automation is a key component of a mature continuous delivery process, which includes: continuous integration, infrastructure automation, and release automation.

After the introduction, they get into some of the basic concepts of continuous delivery and what kinds of steps can make up the full process. From there they get into some of the benefits of its introduction including lower staffing costs and enhanced teamwork. They balance this out with two barriers that could prevent adoption - the initial cost and the organization culture considerations that would need to change.

tagged: continuous delivery deployment benefits barriers automation

Link: http://blog.zend.com/2015/02/09/continuous-delivery-the-benefits-and-barriers-of-automation/

Dutch Web Alliance:
Capifony, Continuous Deployment and Symfony’s parameter.yml
Dec 15, 2014 @ 12:10:50

On the Dutch Web Alliance site today they've posted a tutorial about their use of Capifony for Symfony application deployment and how it relates to updating the "parameter.yml" file. They describe their current deployment process, how it works with the different environments and how they solved the one manually problem they had.

The actual deployment is thus dealt with by capifony. This is a plugin for capistrano written for deploying Symfony applications. [...] Capifony automatically deals with cloning the correct branch on the servers, installing dependencies through composer, migrating database versions etc etc. Basically we don’t have to care about anything else. However, there is one single thing that still keeps on bugging us: when we want to upgrade to a new parameters.yml, we must do this manually. This means that our builds will break when we deploy a version that requires an updated parameters.yml until we manually solve the issue.

To get around this manual issue, they decided on creating a new Capifony task that does an upload/download of the parameters file, depending on the environment.The continuous deployment can then push or pull the file as needed in a more automatic way.

tagged: continuous deployment paramatersyml configuration capifony capistrano task

Link: https://dutchweballiance.nl/techblog/capifony-continuous-deployment-symfonys-parameter-yml/

Automating Laravel Deployments Using Capistrano
Dec 12, 2014 @ 09:15:06

On the AirPair site there's a recent post by Vincent Cardillo showing you how to set up Laravel deployments with Capistrano, a popular Ruby-based deployment automation tool.

Hello friends. In this article we will be discussing automating the deployment of Laravel applications using the Capistrano tool. If you don't know what some of these things are, read on. [...] Why should we bother setting up Capistrano? Can't we just deploy to our servers by hand? Sure, maybe, but this quickly becomes annoying with anything more than a few servers, and isn't a scalable process.

He starts by laying out some of the prerequisites you'll need to get the deployment working: a Laravel application installed, some familiarity with Git/GitHub and a Linux-based system to work from. He talks about two methods of deployment, push and pull, and includes a summary (and illustration) for each. From there he starts to get into the detailed steps of setting up the deployment itself:

  • Protecting sensitive information (like configuration files)
  • Installing Capistrano as a Ruby gem
  • Setting up the SSH keys between systems
  • Setting up the receiving server
  • Setting up the Laravel project in a Capistrano deploy
  • Creating the steps in the deployment workflow
  • Doing the actual deployment

He includes all of the commands and configuration examples you'll need to make the deployment happen. He also finishes off with a few other things Capistrano could do for you including making a "sanity check" file and flushing memcache on deploy.

tagged: laravel deployment capistrano tutorial automate

Link: https://www.airpair.com/laravel/posts/automating-laravel-deployments-using-capistrano

Lee Blue:
PHP vs Ruby – Application Shelf Life
Dec 10, 2014 @ 13:19:15

Lee Blue has started up a series of posts talking about his reasoning for moving back to PHP from Rails in his applications. In his first post of the series, he looks at application "shelf life" and the overall lifespan of the project and how that relates to things like maintainability and upgrade handling.

I plan to write a series of posts about how we develop, deploy, and support our affiliate software and digital downloads applications. And why, after 5 years of Ruby on Rails development we switched back to PHP. One of the reasons is what I refer to as the shelf life of a web application. Let’s talk about what happens to a web application if you just let it sit.

He talks about the "rotting on the vine" that one of his clients' Rails 1.0 application faced when the later versions of the Ruby on Rails framework. He talks about how these kinds of upgrades cost money (and time) and how, with the right selections for the deployment stack, some of the costs could be alleviated. He gives the example of a PHP-based deployment setup and how much of the related technology has been stable and (mostly) unchanging over the years, just with new features being added. He offers a few suggestions to avoid this "app rot" and things startups/freelancers can do to help prevent it in their clients' applications.

tagged: ruby shelflife application rot version deployment stack opinion rubyonrails

Link: http://leehblue.com/php-vs-ruby-application-shelf-life/