• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
From dev to ops and beyond - getting it done
 

From dev to ops and beyond - getting it done

on

  • 3,698 views

About the importance and journy to shipping and DevOps

About the importance and journy to shipping and DevOps

Statistics

Views

Total Views
3,698
Views on SlideShare
3,687
Embed Views
11

Actions

Likes
2
Downloads
11
Comments
0

1 Embed 11

https://twitter.com 11

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    From dev to ops and beyond - getting it done From dev to ops and beyond - getting it done Presentation Transcript

    • FROM DEV TO OPS ANDBEYONDGETTING IT DONEVolker Dusch / @_ _edorian
    • ABOUT MESoftware EngineerPHP since 11 yearsCICleanCodeDevOpsTDDShippingBullet points
    • INSTEAD OF ME
    • WORKING FORResearchGate gives science back to the people who make it happen.We help researchers build reputation and accelerate scientificprogress.On their terms.
    • GET IN TOUCHstackoverflow:Twitter: @_ _edorianG+: Volker DuschIRC: edorianMail: php@wallbash.com
    • 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
    • BUT BEFORE WE GET GOINGTime for a little exercise
    • 10 YEARS AGOHOW I GOT HOOKED ON CREATING STUFF ON THEWEBCreating things is awesomeIt was super easy and fun
    • 10 YEARS AGOCUSTOMERS"We want a website!""Can you fix this little thing please?""What do you mean youre already done?"
    • 10 YEARS AGOWHAT IDIDNT KNOW BACK THENThings got bigger, a lot bigger"Web applications" vs. "Websites"Maintaining things was really hardIts about more than just programming
    • INTERMISSION
    • INTERMISSION
    • MY FIRST WEB APPLICATION6 devs, growing to 20Big code baseQuite some data, for the timeThis talk is about everything we had to take care of, and more
    • SHIPPING BIGGER THINGS
    • LETS SHIP IT!THINGSTO TAKE CARE OFFulfilling current requirementsFiguring out what to do nextDelivery and OperationsASK QUESTIONS AT ANY TIME!
    • WERE DEVELOPERSLets start with us!We get paid to do what we loveMost of us started because we where fascinated by programmingBut what is our job?
    • 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!
    • HOW?Evaluate everything youre doing by a simple question:“Does the practice in question help us to continuouslyship what our business needs to succeed?”
    • CODERules for structuring our source code that have proven to help withsustainability.
    • 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
    • SOLIDSingle responsibilityOpen-closedLiskov substitutionInterface segregationDependency inversionhttp://en.wikipedia.org/wiki/SOLID(object-orienteddesign)
    • COMPOSITION OVER INHERITANCEDont inherit from things if you can just use them.http://c2.com/cgi/wiki?CompositionInsteadOfInheritancehttp://en.wikipedia.org/wiki/Compositionoverinheritance
    • 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.”
    • REUSING CODEThe Dependency Manager for PHPAs easy as committing everything to your SCM. But with care freeautoloading.
    • TESTINGThe art of making sure that you notice failures before your customersdo.Testing exist to give you confidence when moving forward.
    • 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.”
    • CONVENTIONALWISDOM
    • 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
    • ENSURING MAINTAINABILITYGetting rid of all the things you might stumble over
    • 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
    • WORKING IN SHORTITERATIONSEvery iteration is a chance for people to "sync" their Vision of theproduct with the current reality.
    • 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.
    • PLANNING CAN BE A BIG MINDSET CHANGE“Nobody told me my job involved talking to... people”
    • 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.
    • HONESTY SOLVES A LOT MORE ISSUES THAN ITCREATESTrue story.
    • 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
    • BUGSTechnical errorsCommunication errors (and forgotten features)Fix the technical issues quickly to reduce complexityDont build "bug management".But at a certain size you need someone to dispatch bugs to safeeveryone time
    • 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/
    • OPS AND DEVOPSIf its not in production it doesnt really count.
    • CLASSIC APPROACH
    • 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.
    • LINKShttp://abc.tools.qafoo.cohttp://www.capistranorb.com/Example Ant: http://jenkins-php.orghttp://symfony.com/doc/current/components/console/introduction.html
    • 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.
    • THANK YOU!
    • QUESTIONS?Get in touchTwitter: @_ _edorianG+: Volker DuschIRC: edorianMail: php@wallbash.comCheck those things out:Facebook: https://www.facebook.com/Engineering?sk=notesEtsy: http://codeascraft.com/