Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Building Scalable Development Environments


Published on

Published in: Technology
    Are you sure you want to  Yes  No
    Your message goes here

Building Scalable Development Environments

  2. 2. Prologue <ul><li>Who am I ? </li></ul><ul><ul><li>Shahar – Pronunciation is not important! </li></ul></ul><ul><ul><li>Working for Zend Technologies for the last 2½ years </li></ul></ul><ul><ul><li>Spend much of my time watching others work ;) </li></ul></ul><ul><li>Who are you ? </li></ul><ul><ul><li>Executives ? </li></ul></ul><ul><ul><li>Project / Product Managers ? </li></ul></ul><ul><ul><li>Development / Testing Team leaders? </li></ul></ul><ul><ul><li>Developers? </li></ul></ul>
  3. 3. Prologue <ul><li>What is this all about ? </li></ul><ul><ul><li>A semi-technical checklist of good development practices </li></ul></ul><ul><ul><li>No exciting news – most of you probably know / read about / applied some of these practices </li></ul></ul><ul><ul><li>Aimed at helping you build a healthy development environment </li></ul></ul><ul><li>What is this not ? </li></ul><ul><ul><li>In any way related to application or server performance </li></ul></ul><ul><ul><li>A technical guide </li></ul></ul><ul><ul><li>An introduction to specific development or testing methodologies (RAD, XP, Scrum, etc.) </li></ul></ul>
  4. 4. Scalability ? <ul><ul><li>“ scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged.” </li></ul></ul><ul><li>André B. Bondi, Characteristics of scalability and their impact on performance </li></ul>
  5. 5. <ul><li>Develop Fast </li></ul><ul><li>Produce maintainable code </li></ul><ul><li>Avoid introducing new bugs </li></ul><ul><li>Be able to easily refactor as needed (optimize and secure) </li></ul><ul><li>Basically, be able to react to market (ing) demands </li></ul>Scalability in development ?
  6. 6. The Basics: Always-True Best Practices <ul><li>As close as you can to production setup, but: </li></ul><ul><ul><li>E_STRICT | E_NOTICE compatibility </li></ul></ul><ul><ul><li>Restrictive php.ini </li></ul></ul><ul><ul><ul><li>short_open_tags, register_long_vars </li></ul></ul></ul><ul><ul><ul><li>memory_limit </li></ul></ul></ul><ul><ul><ul><li>register_globals, magic_quotes_gpc </li></ul></ul></ul><ul><ul><li>display_errors On </li></ul></ul>
  7. 7. Standard Programming Style <ul><li>Unified coding standards help developers “get into the code” faster </li></ul><ul><li>Less chance of typos that introduce bugs </li></ul><ul><li>Clean Code == Good Code </li></ul><ul><li>Matter of taste, but some basic rules apply to all </li></ul><ul><li>No need to reinvent the wheel: </li></ul><ul><ul><li>PEAR Coding Standards </li></ul></ul><ul><ul><li>The Zend Framework PHP Code Standards </li></ul></ul><ul><ul><li>If you create your own standards, document them </li></ul></ul>
  8. 8. Standard Programming Style <ul><li>Always-true bug-reducing standards: </li></ul><ul><ul><li>Avoid short open tags </li></ul></ul><ul><ul><li>Skip closing tag ( ?> ) when not required </li></ul></ul><ul><ul><ul><li>(you also save a couple of bytes on disk!) </li></ul></ul></ul><ul><ul><li>Use meaningful labels </li></ul></ul><ul><ul><li>Document! </li></ul></ul><ul><ul><li>Be E_NOTICE and E_STRICT compliant: </li></ul></ul><?php echo $info [ VERSION ]; // No good! echo $info [ 'VERSION' ]; // Better! ?>
  9. 9. Standard Programming Style <ul><li>Readability is extremely important </li></ul>// Create the HTTP Client and send the request $client =new Zend_Http_Client ( '' ,array( 'adapter' => 'Zend_Http_Client_Adapter_Proxy' , 'proxy_host' = '' , 'proxy_user' => 'shahar' , 'proxy_pass' => 'secret' )); $client -> request (); // Prepare HTTP client $config = array( 'adapter' => 'Zend_Http_Client_Adapter_Proxy' , 'proxy_host' = '' , 'proxy_user' => 'shahar' , 'proxy_pass' => 'secret' ); $client = new Zend_Http_Client ( '' , $config ); // Send HTTP request $client -> request ();
  10. 10. Peer-Review and Peer-Training <ul><li>Maintain high standards </li></ul><ul><li>Make sure nobody leaves with all your in-house knowhow </li></ul><ul><li>Encourage your developers' natural desire to learn and evolve </li></ul><ul><li>Make architects out of code-monkeys ;) </li></ul>
  11. 11. Source / Revision Control <ul><li>Not just for rolling back your mistakes </li></ul><ul><li>Allows your developers to work on the same modules without interfering with each other's work </li></ul><ul><li>Use advanced features: </li></ul><ul><ul><li>Tag before you release and when testing </li></ul></ul><ul><ul><li>Branch major versions and when working on experimental changes </li></ul></ul><ul><ul><li>Work on trunk, merge into production branches when needed, tag from branches, deploy from tags </li></ul></ul>
  12. 12. Source / Revision Control <ul><li>Enforce good SCM practices: </li></ul><ul><ul><li>Update before you start working </li></ul></ul><ul><ul><li>Run tests before committing </li></ul></ul><ul><ul><li>Commit often </li></ul></ul><ul><ul><ul><li>After fixing a single bug or implementing a single feature </li></ul></ul></ul><ul><ul><ul><li>Daily (?) </li></ul></ul></ul><ul><ul><li>Always use descriptive commit log entries </li></ul></ul><ul><ul><li>Developers who commit broken code should be punished! </li></ul></ul><ul><li>Requires some discipline at first ...but is well worth it! </li></ul>
  13. 13. Source / Revision Control <ul><li>“Classic” Branching Model </li></ul><ul><ul><li>Maintain a separate branch for each major version </li></ul></ul><ul><ul><li>Merge relevant bug fixes to maintenance branch(es) after committing them to TRUNK. </li></ul></ul><ul><ul><li>You can also work on a maintenance branch without changing TRUNK. </li></ul></ul>
  14. 14. Source / Revision Control <ul><li>“Release Once” Branching Model </li></ul><ul><ul><li>One release, lots of merges from TRUNK to “Live” branch </li></ul></ul><ul><ul><li>Probably more suitable for the web </li></ul></ul><ul><ul><li>No distinct major versions </li></ul></ul><ul><ul><li>No back-porting of bug fixes (no maintenance branch) </li></ul></ul><ul><ul><li>You can play with “Experimental” features on a separate branch </li></ul></ul>
  15. 15. Bug Tracking <ul><li>Goes hand in hand with SCM </li></ul><ul><li>Everything should be reported </li></ul><ul><li>Nothing should fall between the cracks </li></ul><ul><li>BTS != TODO list </li></ul><ul><ul><li>Manage versions and targets </li></ul></ul><ul><ul><li>Organize tasks according to their priorities </li></ul></ul><ul><ul><li>Assign tasks to developers </li></ul></ul><ul><ul><li>Make sure bugs are tested after they are “fixed” </li></ul></ul>
  16. 16. Benchmarking and Testing <ul><li>Unit Testing </li></ul><ul><ul><li>Generally executed by the developers during the development phase (eg. Before committing) </li></ul></ul><ul><ul><li>Usually PHPUnit or SimpleTest </li></ul></ul><ul><ul><li>Generate code coverage reports </li></ul></ul><ul><ul><li>New bug == new test </li></ul></ul><ul><li>Functional Testing </li></ul><ul><ul><li>Generally executed by testers during the testing phase </li></ul></ul><ul><ul><li>Build scenarios and test plans </li></ul></ul><ul><ul><li>Be organized as much as you can </li></ul></ul>
  17. 17. Benchmarking and Testing
  18. 18. Benchmarking and Testing <ul><li>Benchmarking </li></ul><ul><ul><li>Build (at least one) typical user browsing scenario </li></ul></ul><ul><ul><li>How many visitors are you expecting? </li></ul></ul><ul><ul><li>Set up your load targets according to your business plans </li></ul></ul><ul><ul><li>Make sure you can withstand those targets </li></ul></ul><ul><ul><li>If not – profile and optimize </li></ul></ul><ul><li>Benchmarking tools: </li></ul><ul><ul><li>AB </li></ul></ul><ul><ul><li>Apache Flood </li></ul></ul><ul><ul><li>JMeter </li></ul></ul><ul><ul><li>WebLoad </li></ul></ul>
  19. 19. Putting It All Together <ul><li>Typical “healthy” development environments are organized in 3 tiers: </li></ul><ul><ul><li>Development </li></ul></ul><ul><ul><li>Staging / Testing </li></ul></ul><ul><ul><li>Production </li></ul></ul>
  20. 20. Putting It All Together – Tier 1 <ul><li>Allow all developers to conveniently work on the entire project without “blocking” each other </li></ul><ul><li>Each developer with it's own working copy, virtual host and DB snapshot </li></ul><ul><li>However the server setup (PHP environment) should be identical and close to production setup </li></ul><ul><li>A single “HEAD” virtual host, auto-updated on each commit will allow you to see “clean” progress </li></ul><ul><li>Once a milestone is reached, it is tagged and pushed into the testing environment </li></ul>
  21. 21. Putting It All Together – Tier 1
  22. 22. Putting It All Together – Tier 2 <ul><li>Staging should be identical in setup to production </li></ul><ul><li>If you plan to run benchmarks on it, it should also have similar (or comparable) hardware </li></ul><ul><li>Test on static code snapshots (== tags), with some meaningful DB data snapshot </li></ul><ul><li>Report all issues into a BTS with clear tag / target tracking </li></ul><ul><li>If release objectives are not met, send back to developers for another RC </li></ul><ul><li>Once you have a good RC tag it again and move to production </li></ul>
  23. 23. Putting It All Together – Tier 2
  24. 24. Putting It All Together – Tier 3 <ul><li>Nobody should have access to production code </li></ul><ul><li>It might be a good idea to do a quick run over the current issues in the BTS, to make sure nothing was left out </li></ul><ul><li>Even minor fixes to production should be versioned and tagged before deployment </li></ul><ul><li>Plan properly for production deployment </li></ul><ul><ul><li>Roll-back procedures, downtime etc. </li></ul></ul><ul><ul><li>Is a DB schema going to change? </li></ul></ul>
  25. 25. Putting It All Together – Tier 3
  26. 26. Epilogue <ul><li>Further Reading: </li></ul><ul><ul><li>Development Methodologies: </li></ul></ul><ul><ul><ul><li>Scrum, XP, FDD and Agile methodologies in general </li></ul></ul></ul><ul><ul><li>Source Control: </li></ul></ul><ul><ul><ul><li>Eric Sink's Source Control Howto </li></ul></ul></ul><ul><ul><ul><li>The Subversion Book </li></ul></ul></ul><ul><ul><li>Bug Tracking </li></ul></ul><ul><ul><ul><li>Simon Tatham's “How to Report Bugs Effectively” </li></ul></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><ul><li>Context Driven Testing School </li></ul></ul></ul>
  27. 27. Thank You! ﺷﻜﺮﺍﹰ Qagaasakuq Grazie Tak Dank U Dankon Kiitos დიდი მადლობა Danke Qujanaq ευχαριστώ Merci どうも Рахмет 감사합니다 سوپاس Баярлалаа aahéhee' Takk Fyrir تشكر Dzięki спасибо Gracias asanteni ขอบคุณ teşekkürler дякую אַ דאַנק ngiyabona תודה 多謝 謝謝 (Any Questions?)