1. Care and Feedingof Large Web Applications Perrin Harkins
3. Arcos, contdCMS with modern AJAX UIE-commerceData warehouse with AJAX query builder GUIE-mail campaign managementAsynchronous job queue systemComprehensive reporting
5. DeploymentHard to generalize.tar.gz filesAlways release full builds, not individual files Consistent state for production system QA installs are accurate copies
6. The CPAN problem“Just use the CPAN shell” Fails too often Installs whatever the latest version is
7. CPAN installer requirements:Install specific versionsInstall from local mediaAllow locally modified versionsFully automated “Erase your hard drive? [n]”Install in a local directorySkip the tests Cluster install Some will never work
8. Our solutionFinds all modules in src/ directory of package (Including ones we hacked)Uses Expect to answer questionsBuilds non-CPAN stuff too Apache mod_perl SWISH-E search engine
9. Why bundle dependencies?Avoid troubleshooting local problemsIf possible, specify Perl, MySQL, OS, etc.Sometimes reality intervenes Hardware support Office politics
10. Next up: binary distributionsCompile takes too long Still just tar? RPMs? PAR?See build system in Krang: http://krancgcms.com/
11. OH HAI!I HELP WIF URINDENTATION!
12. UpgradesNeed full automationGot the database part Schema version number in database Run all upgrade scripts with appropriate names e.g. 2.0 --> 3.0 means run upgrade/V2_1.pm and upgrade/V3_0.pm Hand-written SQL scripts Test mode that upgrades from old schema firstLVM for rollback in QA
13. Configuration● Highly configurable systems must be highly configured● Started with httpd.conf style – Config::ApacheFormat – Basic scoping and inheritance
14. Observations on Configuration● People ignore options they dont understand – If the server starts, it must be ok!● Some comments in a config file == weak documentation● Things you rarely change shouldnt be in the shipped config file
15. I CAN HASMAINTENANCE BRANCH?
16. Version ControlMany tool choices now svn, svk, git... Fight it out and let me know who winsMost projects need at least two branches at all times development stable
17. Very simple version controlMain branch is development Must build and pass testsWhen making a release from a branch, tag it Make a “2.0” tag when you release it
18. Very simple version control, cntdMaintenance branch from that tag for bug fixes “2.x” branchOn maintenance release, merge all changes on maintenance branch to main branch Tag “2.1” on 2.x branch Merge 2.0 --> 2.1 onto main branch
19. Too simple?Not everyone is done at the same timeHard to keep dev branch stable for major changes Feature branches Possible integration problemsBeware of complex merges This is not the Linux kernel Could be a people problemAn alternate point of view http://utsl.gen.nz/talks/git-svn/intro.html
20. HALP!TESTS RFAYLIN!
21. Testing● You all know the drill● Local library for common testing tasks – Log in mech object – Run test SMTP server● Test data setup and teardown – Keep stack, delete in reverse order – Probably easier to just wipe the db