ConFoo 2016: Development to Deployment

Professional Workflow From
Development To Deployment
• Why using FTP to move files live is a bad idea
• Creating simple local dev environments for PHP
• Getting your code into a remotely hosted git
repository
• Deploying using a deployment service
A beginner level session covering:

@rachelandrew | Read more at http://rachelandrew.co.uk/presentations/deploy
Rachel Andrew
http://rachelandrew.co.uk
@rachelandrew
http://grabaperch.com

Many issues coming into support stem from
poor development and deployment processes.

The Big Problems
• Developing directly on live sites or in subfolders of live sites
• Developing in subfolders locally
• Setting up local development environments that are so
different to the eventual live server that there is no
confidence when going live
• Deploying via FTP piecemeal and having sites blow up due to
missing files

What’s the problem with (S)FTP?
• You are transferring files one by one to the server with no
management of that transfer
• One failed transfer can break the site
• Old files may be left on the server - this could be a security
risk in the case of third party software
• Very hard to debug issues caused by missing files especially
where they are deep in third party code

Improving workflow is the best way to give
yourself more hours in the day.

These are baby steps to improved workflow.

We need …
• to develop multiple websites on our own computer.
• to know that our live server and local server support the
same things.
• to deploy our site and have confidence that what is on the live
server is identical to our local version.
• to allow clients to view a site in progress during initial
development and also when making changes in future.

@rachelandrew | Read more at http://rachelandrew.co.uk/presentations/deploy@rachelandrew | Read more at http://rachelandrew.co.uk/presentations/deploy

Working locally

Developing live on the server!
• High chance of making a change that breaks something about
the site.
• No way for the client to preview changes
• Local version in sync? Do we even have a local version?
• If you get to the beach, you’ll be fixing a website. On your
phone. Have fun with that.

Q. How do you deploy your sites to the server?
A. We just edit on the server directly.
8%

Let’s develop in a subfolder!
• Create a ‘newsite’ subfolder and develop the site there
• Potential to make an accidental change to the live site with an
FTP mishap
• If the site is in a subfolder then it doesn’t replicate the live
site. To go live you have to change all of your file paths.
• You are not going to the beach. You are fixing up file paths.
More fun!

File paths and URLs are fundamental to the
web. Changing them on going live is messy
and fragile.

Developing remotely is going to be a slow way
to work.

Mac Users - install Apache, PHP and MySQL
on your machine.

homebrew.sh

https://echo.co/blog/os-x-1010-yosemite-local-development-environment-apache-php-and-mysql-homebrew

MAMP, XAMPP, WAMP

Q. How do you develop sites locally that require a
web server?
A. MAMP, WAMP, XAMPP or similar
63%

Linux
Apache
MySQL
PHP

Take your pick
• Mamp - https://www.mamp.info/en/
• Wamp - http://sourceforge.net/projects/wampserver/
• Xampp - https://www.apachefriends.org
• EasyPHP - http://www.easyphp.org/

VirtualHosts - many websites on one server

Avoid creating your own local version of
developing in a subfolder. Remember - we
don’t want to change file paths to go live!

https://www.mamp.info/en/mamp-pro/

Access multiple sites at client1.dev, client2.dev

In an ideal world your local development
environment is identical to the live server.

http://php.net/manual/en/function.strftime.php

PHP Versions can be different. PHP modules
may not be available on the live server.

Virtual Machines

virtualbox.org

vagrantup.com

https://puphpet.com

https://www.smashingmagazine.com/2015/07/development-to-deployment-workflow/

Upload a PHP file with
this function to find out
what is available on your
live server.
<?php phpinfo();?>

Things to check on your live server
• PHP Version
• Installed modules such as gd for image processing
• post_max_size and upload_max_filesize determine the size
of files that can be uploaded
• max_input_vars is the number of form fields allowed in a
post

Shared Folders

Basic commands for
Vagrant.
// start the VM
> vagrant up
// shut down the VM
> vagrant halt
//destroy the VM
> vagrant destroy
//ssh access
> vagrant ssh

http://vagrantmanager.com/

Share your package with anyone else working
on the site. The whole team can then have the
exact same development setup.

We need …
to develop multiple websites on our own computer
to know that our live server and local server support the same
things
to deploy our site and have confidence that what is on the live
server is identical to our local version
to allow clients to view a site in progress
to leave work early and go to the beach.

http://github.com

http://beanstalkapp.com

If you already have files
you need to add to a git
repository.
cd my-git-repo
git remote add beanstalk
git@accountname.beanstalkapp.com:/gitreponame.git
git push beanstalk

If you are starting a new
project.
git clone https://accountname.git.beanstalkapp.com/
gitreponame.git -o beanstalk
cd gitreponame
echo "This is my new project on Beanstalk." > README
git add README
git commit -m "My first commit."
git push beanstalk master

www.git-tower.com

www.git-tower.com/learn/ebook

Tomorrow at 2pm: Practical Git
for Developers

A branch is a version of your site. We are
deploying the master branch to live.

Production refers to your live site. Staging a
site where changes are tested and previewed.

We make a change to our files, commit and
push them to Beanstalk. The Master Branch
now contains only what should be deployed.

Deploy all the things

Deployment with Beanstalk
• Deployments can be Manual or Automatic
• Automatic deployments happen when code is pushed to the
branch you are deploying
• Manual deployments are triggered by you at Beanstalk once
you are happy to go live
• Once a deploy happens Beanstalk makes sure the code on the
live site matches that in Git, removing deleted files, replacing
modified ones and adding new files

On Deploy
• Beanstalk connects to your server
• ensures that the files on the server match the files in the
branch you are deploying
• on initial deploy all existing files on the server have to be
checked. Your first deploy will be slow!
• subsequent deploys only change things that have changed in
git.

Deployment Tips

Create multiple server configuration files

http://solutions.grabaperch.com/development/multiple-server-config

Use .gitignore to keep things out of Beanstalk

https://github.com/github/gitignore

Our new workflow.
1. Edit files as usual on your computer
2. View your site via a web server on that computer
3. Commit changes to Git
4. Push to Beanstalk
5. Login to Beanstalk and hit Deploy
6. Go to the beach.

Databases and Uploaded Assets

Add CMS managed asset folders to
a .gitignore file so they are not committed

Use a CDN for assets if your CMS enables it.
Faster download speeds with bonus ease of
management across environments.

Initial deploy to live also involves an export
and import of the MySQL database.

How to deal with schema or even data
changes on an existing site?

How do you manage database changes between development and live?
“try to keep live db current, and keep list of
changes in settings on dev environment.
this is the one thing that needs a better
solution in my development workflow, esp.
when working together with other
developers on one project.”

How do you manage database changes between development and live?
“Labour intensively. Save a dump of the
live version. Then compare the structure of
the development and live structures in a
diff checker. Finally make the updates
required on the live version, importing the
new data. ”

Create a Maintenance Window where no
changes are made to live.

https://deliciousbrains.com/wp-migrate-db-pro/

http://www.navicat.com/products/navicat-for-mysql

A Staging Server

Using an inexpensive VPS you can create sites
at clientname.yourcompany.com for preview.

You can deploy the master branch to staging
to check before deploying to production.

Even better, you can use your staging server
to deploy commits to a staging branch.

Deploy with a tag to any commit or push
comment. For example: [Deploy: Staging]

Try to keep your Master branch deployable to
live. If disaster strikes you can redeploy.

Remember to backup your database and
any resources regularly!

Logging in and downloading the assets when
you remember is not a backup strategy.

Bonus feature! We can now easily switch
hosting if our current host becomes unreliable.

Unsolved problems

There are product opportunities in helping
people in shared PHP hosting land navigate
these issues.

Pre and post-processed CSS and
JavaScript files.

Backup of CMS-managed resources

Database migrations

We can …
develop multiple websites on our own computer
know that our live server and local server support the same
things
deploy our site and have confidence that what is on the live
server is identical to our local version
allow clients to view a site in progress
leave work early and go to the beach.

@rachelandrew | Read more at http://rachelandrew.co.uk/presentations/deploy@rachelandrew | Read more at http://rachelandrew.co.uk/presentations/deploy
Thank you!
Slides & resources at:
http://rachelandrew.co.uk/presentations/deploy
@rachelandrew

ConFoo 2016: Development to Deployment

More Related Content

What's hot

Viewers also liked

Similar to ConFoo 2016: Development to Deployment

More from Rachel Andrew

ConFoo 2016: Development to Deployment