taming the deployment beast

Deployment Beast

Zend/PHP Conference & ExpoSan Jose, CA10.20.2009

the

Taming

Wednesday, October 21, 2009

What is Deployment?

HERE THERE

The fun part is what happens in between...

- technology- configuration- coordination- an increase in sanity


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


Thinking EnvironmentallyDevelopmentEnvironment for application development (includes version control, unit testing, lint checks)

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

StagingEnvironment immediately prior to deployment to production, checkout of current files marked for "production"

ProductionEnvironment for public consumption


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

Acceptance/SystemRun "in browser" to validate functionality of the applications

CompatibilityEnsuring that the software will work with all platforms involved

PerformanceChecking performance of the application on all sides

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


Version Control Makes it SimpleCVSVersion control system, each file has its own version number, uses tags and pseudo branches for code separation

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

GitVersion control system, each checkout is a full repository in its own right, allows for offline commits, updates/merges once connected


Pushin’ DataDatabase migration toolsVersion control system, each file has its own version number, uses tags and pseudo branches for code separation

Keep it in version control tooVersion control system, repository has overall version number, uses tags/branches for code separation

GitVersion control system, each checkout is a full repository in its own right, allows for offline commits, updates/merges once connected


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

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

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


Document Your CodephpDocumentor

Uses code comments to build documentationExamples:/*** This library (MyLib) provides this bit of functionality* @author Chris Cornutt <[email protected]>* @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 WikipediaDocument the “why”, not really the “how”Easy to get out of control


mailto:[email protected]


Frontend TestingSelenium

Firefox extensionSession recording for typing, clicks, etcThree flavors: Selenium IDE, Selenium Remote Control, Seleium GridMultiple browser support (IE, Firefox, Safari, Chrome)

WebTestsBased on an Ant build processBuild XML-based repeatable testsWorries more about the page than how its renderedOutput reports on test results


Continuous IntegrationphpUnderControl (CruiseControl)

CruiseControl is Java-based, but build tools for Ant, Phing, Rake, etcPlugins for git, svn, cvsOutput methods include emails, ftp, http, jabber, etc

pUc adds integration for things like PHPUnit, phpDocumentor, PHP_CodeSnifferChart output for unit test coverage, coding violations, timeline

Xinc (Native PHP)Written in PHP5 with built-in SVN supportStats output for build status, testing summary, durationInstallable via PEAR


Syntax ToolsTidy

Extension for PHP (http://php.net/tidy)Parsing XML and HTMLCan specify a custom configuration fileCleanRepair is your best friend

PHP_CodeSnifferReduces the code to “tokens” & checks location, surroundings to ensure complianceComes with default “sniffs” - PEAR, PHPCS, Zend, SquizCommand 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

--------------------------------------------------------------------------------


http://php.net/tidy

http://php.net/tidy

Deployment Options

SVN (svn up)ssh/scprsyncftp/sftp

PEAR installerphar packages

Other manual/automatic process


Enough TalkIt’s Time for Some Action


20090716-05

Overview

DEVUnitTest

LintCheck

BuildDocs

CodeStandard

SubversionPHPUnit

phpDocumentorPHP’s lint

PHP_CodeSnifferrsync

Phing / Ant

PRODrsyncsvn co

DBDeploy PEAR TarZip Report


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

Who’s going to run this thing?


Step 2 - DevelopmentSingle 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”.

PROD

DEV

QA


Step 3 - The BuildDetermine the steps you’ll needThink EasyServer builds are good + Local build is even better

Example:Phing configuration 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 ofall files and run an rsync script to push it out live.


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>


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>


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 youThings to consider: network config, what’s already in use (piggyback on a protocol?)

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


Step 4 - The Push (cont.)

2%2%4%4%

4%

5%

11%

21%

47%

SVN FTP/SFTPRSYNC CapistranoSSH/SCP AntAutomatic Cut & PasteManual


Step 5 - The Aftermath

Clean up your mess, young manThis is where post-push belongs, wrap it all up

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

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


That’s All, Right?Murphy has this law...Perfect deployment is a myth

Must be able to roll backA similar “single-button” solution

Most tools can helpIncluded rollback feature, or just the ability to pull the previous version

Easier with code, harder with dataDatabase rollbacks can be tricky


The Point of it All

Like flipping 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.


Questions,Comments,

[email protected]

@enygma

http://blog.phpdeveloper.org

http://joind.in/talk/view/902








taming the deployment beast

Technology

code testing

overall version number

phing phpbased build

ant build process

build status

local build

code phpdocumentor

code comments