Building Scalable Development Environments

Slide 1: BUILDING SCALABLE DEVELOPMENT ENVIRONMENTS Shahar Evron, Zend Technologies

Slide 2: Prologue • Who am I ?  Shahar – Pronunciation is not important!  Working for Zend Technologies for the last 2½ years  Spend much of my time watching others work ;) • Who are you ? Executives ?  Project / Product Managers ?  Development / Testing Team leaders?  Developers?  Oct 10, 2007 PAGE 2

Slide 3: Prologue • What is this all about ?  A semi-technical checklist of good development practices  No exciting news – most of you probably know / read about / applied some of these practices  Aimed at helping you build a healthy development environment • What is this not ?  In any way related to application or server performance  A technical guide  An introduction to specific development or testing methodologies (RAD, XP, Scrum, etc.) Oct 10, 2007 PAGE 3

Slide 4: Scalability ? “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.” André B. Bondi, Characteristics of scalability and their impact on performance Oct 10, 2007 PAGE 4

Slide 5: Scalability in development ? • Develop Fast • Produce maintainable code • Avoid introducing new bugs • Be able to easily refactor as needed (optimize and secure) • Basically, be able to react to market(ing) demands Oct 10, 2007 PAGE 5

Slide 6: The Basics: Always-True Best Practices • As close as you can to production setup, but:  E_STRICT | E_NOTICE compatibility  Restrictive php.ini • short_open_tags, register_long_vars • memory_limit • register_globals, magic_quotes_gpc  display_errors On Oct 10, 2007 PAGE 6

Slide 7: Standard Programming Style • Unified coding standards help developers “get into the code” faster • Less chance of typos that introduce bugs • Clean Code == Good Code • Matter of taste, but some basic rules apply to all • No need to reinvent the wheel:  PEAR Coding Standards  The Zend Framework PHP Code Standards  If you create your own standards, document them Oct 10, 2007 PAGE 7

Slide 8: Standard Programming Style • Always-true bug-reducing standards:  Avoid short open tags  Skip closing tag (?>) when not required • (you also save a couple of bytes on disk!)  Use meaningful labels  Document!  Be E_NOTICE and E_STRICT compliant: <?php echo $info[VERSION]; // No good! echo $info['VERSION']; // Better! ?> Oct 10, 2007 PAGE 8

Slide 9: Standard Programming Style • Readability is extremely important // Create the HTTP Client and send the request $client=new Zend_Http_Client('http://www.example.com/',array( 'adapter'=>'Zend_Http_Client_Adapter_Proxy','proxy_host'='10.1.2.3', 'proxy_user'=>'shahar','proxy_pass'=>'secret')); $client->request(); // Prepare HTTP client $config = array('adapter' => 'Zend_Http_Client_Adapter_Proxy', 'proxy_host' = '10.1.2.3', 'proxy_user' => 'shahar', 'proxy_pass' => 'secret'); $client = new Zend_Http_Client('http://www.example.com/', $config); // Send HTTP request $client->request(); Oct 10, 2007 PAGE 9

Slide 10: Peer-Review and Peer-Training • Maintain high standards • Make sure nobody leaves with all your in-house knowhow • Encourage your developers' natural desire to learn and evolve • Make architects out of code-monkeys ;) PAGE Oct 10, 2007 10

Slide 11: Source / Revision Control • Not just for rolling back your mistakes • Allows your developers to work on the same modules without interfering with each other's work • Use advanced features:  Tag before you release and when testing  Branch major versions and when working on experimental changes  Work on trunk, merge into production branches when needed, tag from branches, deploy from tags PAGE Oct 10, 2007 11

Slide 12: Source / Revision Control • Enforce good SCM practices:  Update before you start working  Run tests before committing  Commit often • After fixing a single bug or implementing a single feature • Daily (?)  Always use descriptive commit log entries  Developers who commit broken code should be punished! • Requires some discipline at first ...but is well worth it! PAGE Oct 10, 2007 12

Slide 13: Source / Revision Control • “Classic” Branching Model  Maintain a separate branch for each major version  Merge relevant bug fixes to maintenance branch(es) after committing them to TRUNK.  You can also work on a maintenance branch without changing TRUNK. PAGE Oct 10, 2007 13

Slide 14: Source / Revision Control • “Release Once” Branching Model One release, lots of merges from TRUNK to “Live” branch  Probably more suitable for the web  No distinct major versions  No back-porting of bug fixes (no maintenance branch)  You can play with “Experimental” features on a separate  branch PAGE Oct 10, 2007 14

Slide 15: Bug Tracking • Goes hand in hand with SCM • Everything should be reported • Nothing should fall between the cracks • BTS != TODO list Manage versions and targets  Organize tasks according to their priorities  Assign tasks to developers  Make sure bugs are tested after they are “fixed”  PAGE Oct 10, 2007 15

Slide 16: Benchmarking and Testing • Unit Testing  Generally executed by the developers during the development phase (eg. Before committing)  Usually PHPUnit or SimpleTest  Generate code coverage reports  New bug == new test • Functional Testing  Generally executed by testers during the testing phase  Build scenarios and test plans  Be organized as much as you can PAGE Oct 10, 2007 16

Slide 17: Benchmarking and Testing PAGE Oct 10, 2007 17

Slide 18: Benchmarking and Testing • Benchmarking Build (at least one) typical user browsing scenario  How many visitors are you expecting?  Set up your load targets according to your business plans  Make sure you can withstand those targets  If not – profile and optimize  • Benchmarking tools: AB  Apache Flood  JMeter  WebLoad  PAGE Oct 10, 2007 18

Slide 19: Putting It All Together • Typical “healthy” development environments are organized in 3 tiers:  Development  Staging / Testing  Production PAGE Oct 10, 2007 19

Slide 20: Putting It All Together – Tier 1 • Allow all developers to conveniently work on the entire project without “blocking” each other • Each developer with it's own working copy, virtual host and DB snapshot • However the server setup (PHP environment) should be identical and close to production setup • A single “HEAD” virtual host, auto-updated on each commit will allow you to see “clean” progress • Once a milestone is reached, it is tagged and pushed into the testing environment PAGE Oct 10, 2007 20

Slide 21: Putting It All Together – Tier 1 PAGE Oct 10, 2007 21

Slide 22: Putting It All Together – Tier 2 • Staging should be identical in setup to production • If you plan to run benchmarks on it, it should also have similar (or comparable) hardware • Test on static code snapshots (== tags), with some meaningful DB data snapshot • Report all issues into a BTS with clear tag / target tracking • If release objectives are not met, send back to developers for another RC • Once you have a good RC tag it again and move to production PAGE Oct 10, 2007 22

Slide 24: Putting It All Together – Tier 3 • Nobody should have access to production code • 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 • Even minor fixes to production should be versioned and tagged before deployment • Plan properly for production deployment  Roll-back procedures, downtime etc.  Is a DB schema going to change? PAGE Oct 10, 2007 24

Slide 26: Epilogue • Further Reading:  Development Methodologies: • Scrum, XP, FDD and Agile methodologies in general  Source Control: • Eric Sink's Source Control Howto • The Subversion Book  Bug Tracking • Simon Tatham's “How to Report Bugs Effectively”  Testing • Context Driven Testing School PAGE Oct 10, 2007 26

Slide 27: спасибо ‫אַ דאַנק‬ Dank U ‫تشﻜﺮ‬ Qujanaq დიდი მადლობა Tak どうも ‫ﺷﻜﺮﺍﹰ‬ ngiyabona asanteni ขอบคุณ 감사합니다 多謝 Dankon ευχαριστώ Thank You! aahéhee' 謝謝 Gracias Takk Fyrir дякую ‫תודה‬ Рахмет Grazie Qagaasakuq Kiitos ‫سوپاس‬ teşekkürler Баярлалаа Merci Dzięki Danke (Any Questions?)

Slideshare.net (beta)