O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
AGENDAWe will look at what
is necessarily to keep shipping a successfulproduct beyond its initial release and what role we developers shouldbe playing in this.Development practicesPlanning and CommunicationDeployment and OperationsYMMV
OUR JOB IS TO DELIVERGet
things doneGive good estimatesAsk the right questionsKeep doing thatDont slow downKeep our promises
THE COST OF HAVING USFOLKSAROUNDGerman
numbers, YMMV €, ApproximationsSalary: ~50k a year 50.000€ / YearAdding non-wage labor cost 80.000€ / YearOffice space, water, hardware, coffee,plants, cleaning, travels, training100.000€ / YearWeekends, holidays, vacation, etc:We works 220 days a year.455€ / day"Classic" 8 hour work day 55 Bucks per Hour!We are expected to contribute over 100.000 Bucks in business valueper year!
THE MOST BASIC THING:Separate the
web-glue from the business logic.Keep templates stupidHave services owning the logic for manipulation of business entitiesHide the data access behind a layer that you can maintainindividually
DEPENDENCYINJECTIONThis goes for you code
base as well as for your whole Company.Allows for quick and easy reuse of small componentsIf wiring is to hard people will copy/paste insteadCan be achieved in many ways. Pick one that works for youhttp://pimple.sensiolabs.org/http://symfony.com/doc/current/components/dependency_injection/index.hhttps://github.com/researchgate/injektor“In the end - everything is a wiring problem.”
THE FASTEST THING YOUCAN DOStaging
serverTesting your buildsAll without even touching Behat or PHPUnithits=`curl -s staging.project.com | grep Login: | wc -l`;test $hits -eq 1 || echo "Frontpage error!"data="login=test&passwort=secure&csrf="$csrfTokenurl="staging.project.com"hits=`curl -X POST -d $data $url | grep Hello, testuser | wc -l`;test $hits -eq 1 || echo "Login error!"
OTHER DEPARTMENTSDONT CARE ABOUT UNIT
TESTINGNor should they!Your fellow developers on the other hand ... :)“The mechanic fixing your car doesnt ask you whatsong she should listen to while performing the task.”
BUT TESTING ISHAAAARDWriting proper code
is hardThe harder it is to use the code in question, the harder is writing testsfor itComplex tests means the code is to complex. Break it down.If anything: Mocking is hard(-ish).Phake is your friend:http://phake.digitalsandwich.com/docs/html/FBMock: Mocking for grown ups:https://github.com/facebook/FBMockThe PHPUnit mocking API is still good enough.
TDDWriting tests can feel like
extra work if you are rethinking an alreadysolved problemTDD offers a way to first think about the problem, the interface andthe interactions and then filling in the details step by step until you aredone with the bigger picture.
QUICK WINSWITH BEHATWeb tests help
you detect a big amount of wiring issues with littleeffortBefore growing to many of them consider maintenance"Full stack testing" will allow you to ship with great confidence
CODE REVIEWThere are a lot
of ways to go about thisSmall teams can use commit based reviewWhen feature branching the merge back is a natural pointInternal coding DojoPair programmingSend emails when important changes occurThe main point of these ideas is to make sure everyone has a goodunderstanding of how common things are solved and to keep peoplecommunicating.
CODING GUIDELINESA collection for formatting
and structure rules so that everyone caneasily find their way around and produce uniform code.Just create the rule set fitting your practicesAdapt when there is painDont over analyze. Just do itPHP CodeSniffer:http://pear.php.net/package/PHP_CodeSnifferhttp://pear.php.net/manual/en/package.php.php-codesniffer.annotated-ruleset.phphttp://edorian.github.io/php-coding-standard-generator/#phpcs“Coding rules:It doesnt matter what they are - as long as you havethem.”
COMPLEXITYGUIDELINESSimilar to a coding standard
but focusing on hunting down potentialproblems within your source codePossible bugsSuboptimal codeOvercomplicated expressionsUnused parameters, methods, propertiesPHP MessDetector:http://phpmd.org/http://phpmd.org/rules/http://edorian.github.io/php-coding-standard-generator/#phpmd
CONTINUOUS DEVELOPMENT PACE"Done" means there
is nothing left to clean upEvery once in a while you plan time to throw away things"Having a clean slate" is an attitude and a culture“There are only two hard problems in ComputerScience: cache invalidation, naming things, and off-by-one errors.”
CIHave a automated way of
checking all the things you agreed onRun web and unit testsEnsure coding guidelinesEnsure complexity guidelinesKeep the project deploying :)Tools:http://jenkins-ci.orghttp://jenkins-php.orghttp://www.sonarsource.org
SHIPPING REDUCES COMPLEXITY"Did we already
implement this a month ago?""That bug you just reported was fixed 2 weeks ago. Just notdeployed yet"Shipping lets you discover what doesnt work before you spend toomuch time on it.
ASSUME COMPETENCEWork with the basic
mind set that other people are at least as good intheir job as you are in yours.If they tell you to do "stupid" things find out what they want toachieveCompany "vision" is a big hereJust know what you want to get done and work together
HAVING EVERYONE INVOLVEDGetting everyone in
the same boat and working towards a commongoal will speed you up like nothing else every will.ProductDesignCopyrightingEngineering""Upper management""If you can ensure that everyone was involved somewhere in the loopyou spend way less time on re-discussing and avoid confusion.
TOOLINGTooling is needed when people
cant get the information they needA wall with Postit notes and a stack of story cards might be all youneedWhen working remote spend time on making it look beautiful so thatpeople look at ithttps://trello.com/$millionOfOtherProducts
STATSState are awesome!Knowing what your
users actually do with your software is valuableSeeing them use the new thing you build is - like - the best ever(tm).StatsD: https://github.com/etsy/statsd/Graphite: http://graphite.wikidot.com/
DEVOPSTalking to the people getting
up at night so you dont have to.Your SysAdmins care. A lot!Its your job to figure out a way to constantly deploy withoutbreaking thingsAutomation helps avoiding errors
BUILD AND DEPLOYMENT TOOLINGA collection
of scripts that gets you from "source code" to "running inproduction".Create a buildCan be done in Jenkins. Still keep it in a script and let Jenkins runit.Run unit testsRun integration, functional testsReport on coding/complexity metricsOnce you are confident that things are going to go wellDeploy the build to a staging environmentRun web testsDeploy to productionRollback when really really neededThats it. No magic - Just detail work.
HOW TO GET THAT SCRIPT?It
doesnt matter what language you write that tooling in. There is nogeneric answer.Chances are there is going to be a lot of BASH in it.Whatever calls your BASH script isnt all that importantAntMore custom BASHAnt Build CommonsSF2 CLI commandsWhatever works. As long as you can maintain it and its stable.Dont over-engineer. Youll iterate a lot over this.
PROVISIONINGGetting servers and development environments
in a known stateHaving the SAME versions on dev and prod is invaluable.The only documentation that gets always updated is the code.Being able to recreate servers safes a lot of hassle.Think about your firewalls :)Having a virtual machine per project keeps you sanehttp://www.vagrantup.com/https://puppetlabs.com/http://www.opscode.com/chef/
CONFIGURATION MANAGEMENTAny solution will require
close collaboration with the folks running theproduction boxes or lead to hassle.Config files in puppet/chefConfigs for all systems in the SCM and only reading in environmentsSetting systems up in a way that they always look the same
DATA MIGRATIONSThis questions comes up
a lot when talking about automation. There isno easy answer.Very specific to your project and environmentUsually not possible to have downtime while data is migratedDont throw away DB columns when you change the code. Add newones and clean up later when you are sure.