Shipping code that works is crucial to retaining the support of customers and high quality in your application. While it’s impossible to ship code without any bugs at all, it is possible to control for as many as possible, and fix as many known issues as there is time. These strategies are designed to ensure that code works when it is shipped to the end user.
Developers have a tendency to test their code only with expected data. Testers, on the other hand, aren’t developers themselves; instead, they will use data that you don’t expect and find bugs that your users might otherwise experience.
Wednesday, January 13th, 2010 @ 1:00 am |
Comment (2) |
Categories: Best Practices, Technology
Tags: testing, continuous integration
Often when I’m on a job interview, I’ll ask whether or not the company I’m talking with makes use of an automated build system of any kind. More often than not, the answer I get is somewhere along the lines of “build systems are irrelevant to the web; we can simply upload changes instantly.”
This thinking could not be farther from the truth. Build systems are just as relevant to the web (if not more so) than they are to compiled code. Build systems offer significant advantages to the development of software applications, and it is crucial that developers not take them for granted.
Friday, January 8th, 2010 @ 1:00 am |
Comment (3) |
Categories: Technology, Best Practices
Tags: build system, automated build, continuous integration, phing, build scripts
Trac. CruiseControl. phpUnderControl. Jira. Bugzilla. These are all intensely popular development tools. And not a single one of them is written in PHP.
Friday, December 4th, 2009 @ 1:00 am |
Comment (74) |
Categories: Technology, Community
Tags: Trac, Community, continuous integration