Taming the Deployment Beast

Taming the

Deployment
Beast DallasPHP - Dallas, TX
08.11.2009

Monday, August 17, 2009

What is Deployment?

HERE THERE

The fun part is what happens in between...
- technology
- conﬁguration
- coordination
- an increase in sanity

20090716-01

What’s included in Deployment?
- code testing
- building documentation
- checking permissions
- check coding standards
- updates/uninstall of components
- notiﬁcations

20090716-02

Thinking Environmentally
Development
Environment for application development (includes version control, unit testing, lint checks)

Quality Assurance/Testing
Environment for testing applications and ensuring all is functioning well

Staging
Environment immediately prior to deployment to production, checkout of current ﬁles
marked for "production"

Production
Environment for public consumption

20090716-02

Don’t Forget the Testing
Integration
Unit/other tests designed to identify potential errors with the communication
between pieces of functionality

Acceptance/System
Run "in browser" to validate functionality of the applications

Compatibility
Ensuring that the software will work with all platforms involved

Performance
Checking performance of the application on all sides

Security
Verifying that no security issues exist in the code for any stage in the process

20090716-04

Version Control Makes it Simple
CVS
Version control system, each ﬁle has its own version number, uses tags and
pseudo branches for code separation

Subversion
Version control system, repository has overall version number, uses tags/
branches for code separation

Git
Version control system, each checkout is a full repository in its own right,
allows for oﬄine commits, updates/merges once connected

20090716-03

Build it Out
Phing
PHP-based build tool, automates the build process for a site to be deployed.
XML-based build file for simple management (PHP)

Ant
Apache's build tool, designed for flexibility for multiple deployment types.
XML-based configuration files (Java)

Capistrano
Tool for automation of tasks on multiple servers (as opposed to just a local build).
Allows for rollbacks. (Ruby)

20090716-05

Document Your Code
phpDocumentor
Uses code comments to build documentation
Examples:
/**
* This library (MyLib) provides this bit of functionality
* @author Chris Cornutt <ccornutt@phpdeveloper.org>
* @package mylibs
*/
class MyLib { }
//------------------
/**
* This method takes in things and outputs others
* @param array $arr_in Input Array
* @param string $str_in Input String
* @return object $obj_out Output object
*/
public function myMethod($arr_in,$str_in,$obj_out){
return $obj_out;
}

Wiki software (like MediaWiki)
Used by Wikipedia
Document the “why”, not really the “how”
Easy to get out of control
20090716-04

Frontend Testing
Selenium
Firefox extension
Session recording for typing, clicks, etc
Three ﬂavors: Selenium IDE, Selenium Remote Control, Seleium Grid
Multiple browser support (IE, Firefox, Safari, Chrome)

WebTests
Based on an Ant build process
Build XML-based repeatable tests
Worries more about the page than how its rendered
Output reports on test results

20090716-04

Continuous Integration
phpUnderControl (CruiseControl)
CruiseControl is Java-based, but build tools for Ant, Phing, Rake, etc
Plugins for git, svn, cvs
Output methods include emails, ftp, http, jabber, etc

pUc adds integration for things like PHPUnit, phpDocumentor, PHP_CodeSniﬀer
Chart output for unit test coverage, coding violations, timeline

Xinc (Native PHP)
Written in PHP5 with built-in SVN support
Stats output for build status, testing summary, duration
Installable via PEAR

20090716-04

Syntax Tools
Tidy
Extension for PHP (http://php.net/tidy)
Parsing XML and HTML
Can specify a custom configuration file
CleanRepair is your best friend

PHP_CodeSniffer
Reduces the code to “tokens” & checks location, surroundings to ensure compliance
Comes with default “sniffs” - PEAR, PHPCS, Zend, Squiz
Command line tool: phpcs

FILE: /path/to/code/myfile.php
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AND 1 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
2 | ERROR | Missing file doc comment
20 | ERROR | PHP keywords must be lowercase; expected "false" but found
| | "FALSE"
88 | ERROR | Line not indented correctly; expected 9 spaces but found 6
--------------------------------------------------------------------------------
20090716-04

Deployment Options
SVN (svn up) PEAR installer
ssh/scp phar packages
rsync
ftp/sftp Other manual/automatic process

20090716-05

Enough Talk
It’s Time for Some Action

20090716-05

Overview
Phing / Ant
Unit Build
svn co Test Docs rsync
DEV PROD
Lint Code
Check Standard

Subversion
PHPUnit
phpDocumentor
PHP’s lint
PHP_CodeSniﬀer
rsync

Zip DB
Deploy PEAR Report Tar
20090716-05

Step 1 - Planning
What do we have right now?
What business processes/workﬂows need to be
considered?
Which technologies would we need to invest in?
What’s our release schedule?

Who’s going to run this thing?

20090716-05

Step 2 - Development
Single place to pull from
(You do use version control, right?)

Example:
Subversion environment with developer branches as well as QA and
PROD branches. PROD branch is “the point”.

QA
PROD

DEV

20090716-05

Step 3 - The Build
Determine the steps you’ll need
Think Easy
Server builds are good + Local build is even better

Example:
Phing conﬁguration that includes an anonymous checkout of the latest from the repository,
a run of all unit tests for the project, generate the docs via phpDocumentor, check the syntax of
all ﬁles and run an rsync script to push it out live.

20090716-05

Step 3 - The Build (Phing)
<?xml version=”1.0”>
<project name=”deploy_me” default=”main”>
<property name=”version” value=”1.0” />

<target name=”unittest”>
<phpunit>
<batchtest>
<fileset dir=”/www/mysite/tests”>
<include name=”**/*Test*.php” />
</fileset>
</batchtest>
</phpunit>
</target>
<target name=”phpdoc” depends=”unittest”>
<phpdoc title=”MySite Documentation” destdir=”/www/mysite/docs” output=”HTML:Smarty:PHP”>
<fileset dir=”/www/mysite/docroot”>
<include name=”**/*.php” />
</fileset>
</phpdoc>
</target>
<target name=”lintme” depends=”phpdoc”>
<phplint>
<fileset dir=”/www/mysite/docroot”>
<include name=”**/*.php” />
</fileset>
</phplint>
</target>
<target name=”standardsplz” depends=”lintme”>
<phpcodesniffer standard=”PEAR” format=”summary” file=”/www/mysite/docroot”
allowedFileExtensions=”php php5 inc” />
</target>
<target name=”main” depends=”standardsplz”>
</target>
</project>

20090716-05

Step 3 - The Build (Ant)
<?xml version=”1.0”>
<project name="deploy_me" default="main" basedir=".">
<property name="version" value="1.0"/>

<target name="unittest">
<exec dir="${basedir}/source" executable="phpunit" failonerror="true">
<arg line="--log-xml ${basedir}/build/logs/testlog.xml"/>
</exec>
</target>
<target name="phpdoc" depends="unittest">
<exec executable="phpdoc" dir="${basedir}/source">
<arg line="-ct type -ue on -t ${basedir}/build/api -tb /PATH/TO/YOUR/PHPUC/DATA/phpdoc -o
HTML:Phpuc:phpuc -d src/"/>
</exec>
</target>
<target name="lintme" depends="phpdoc">
</target>
<target name="standardsplz" depends="lintme">
<exec executable="phpcs" dir="${basedir}/source" output="${basedir}/build/logs/checkstyle.xml">
<arg line="--report=checkstyle --standard=PEAR --ignore=src/autoload src/"/>
</exec>
</target>
<target name="main" depends="standardsplz">
</target>
</project>

20090716-05

Step 4 - The Push
Where’s “here” and where’s “there”?
And what’s in between that could cause issues...

Pick the right tools & process for you
Things to consider: network conﬁg, what’s already in use (piggyback on a protocol?)

Ready...Set...Wait
Do you have everything you need? Is the staging environment ready?

20090716-05

Step 4 - The Push (cont.)
SVN FTP/SFTP
RSYNC Capistrano
2%
4%2% SSH/SCP Ant
4% Automatic Cut & Paste
4% Manual
5%
47%
11%

21%

20090716-05

Step 5 - The Aftermath
Clean up your mess, young man
This is where post-push belongs, wrap it all up

Make sure dev is ready to do it all again
Deployment should be simple and automatic

Giving the “All Clear”
Be sure to run your tests to ensure that all is happy in production.

20090716-05

The Point of it All
Like ﬂipping a switch, a good build should make
deploying your website a simple task, no matter
the complexity.

It should remove the burden of repetitive tasks
from developers and make lives easier.

20090716-05

Questions,
Comments,
Suggestions?
ccornutt@phpdeveloper.org

@enygma

http://blog.phpdeveloper.org

20090716-05

Taming the Deployment Beast

More Related Content

Viewers also liked

Similar to Taming the Deployment Beast

Recently uploaded

Taming the Deployment Beast