Our early-early bird special discount for CodeWorks 09, the amazing seven-city conference series that will travel across the U.S. this September, expires tonight.

With stops in San Francisco, Los Angeles, Dallas, Atlanta, Miami, Washington D.C. and New York City, and some of the best-known expert PHP speakers in the world, CW09 is a great opportunity to discover new PHP features and programming techniques—as well as networking with fellow developers and IT professionals.

Even better, with our early-early bird discount, you can still
get a piece of the action for as little as $99—but only until tonight. Sign up now before it’s too late!

Our Free CodeWorks 09 Summer Webcast Series, sponsored by Microsoft’s Interoperability Lab, continues with a new, completely free webcast hosted by Stefan Priebsch of the PHP consulting company.

Stefan, who is also the author of php|architect’s Guide to PHP 5 Migration, will illustrate some of the new features in PHP 5.3 and discuss the best strategies for upgrading your applications to work with the latest version of PHP.

You can sign up for this free webcast on our Summer Webcast Series page (where you can also sign up for the other upcoming webinars in the series!).

The recording for last Friday’s webcast  Play-doh: Towards Better Object Modeling, hosted by Matthew Weier O’Phinney and part of our popular Summer Webcast Series, sponsored by Microsoft’s Interoperability Labs is now
available directly on our site.

This year’s summer webcast series is turning out to be very popular—but we still have spots available for our upcoming presentations, including webcasts from Cal Evans, Derick Rethans, Stefan Priebsch, Andrei Zmievski and many, many more. Sign up today!

Editor’s Note: This article is second in a three-part series on Development, Testing, Acceptance and Production (DTAP). You can read the first part here .

In the previous part of this series, we discussed the main pieces needed for a proper development environment. However, there are other, smaller pieces, scripts, subsystems and other very important components of a properly-configured development environment that don’t fit in the acronym.

Source Code Control

A well-configured source code control system and source code repository is very important to any development team. Open source
tools like Subversion and CVS are the gold standards in this area, while new tools like GIT are making inroads as well. Whichever tool you choose, make sure it is being used by all and that it is properly configured for your needs.

Unit Testing

If everybody knows that Unit testing is a good idea, why are there teams that still don’t do it? Your testing coverage will vary by client and project, but, at the very minimum, you should have unit tests in place that exercise the major components of your
system.

When and where unit testing is performed depends on what you are comfortable with. Some teams add hooks into their source code control system to run the appropriate checks and accept or deny code based on the success or failure of the unit tests. Other teams, schedule routine checkouts, run the tests for the entire system and publish the results internally for all to see and fix.

However you decide to deploy it, remember that unit testing has a powerful ROI in helping you find bugs early as opposed to late.
For PHP,   PHPUnit is widely accepted as the open-source tool of choice. There are other Unit testing
frameworks available, though.

Integration/regression Testing

I’m always surprised when I find teams that do not perform routine integration and regression testing. Whereas unit testing makes sure all the individual pieces all work properly, integration testing makes sure they all work together. Regression testing, a very important step
that many teams skip, makes sure that test plans from previous phases still work as new code is rolled in.

These tests can be as simple as manually executing a testing plan on a regular basis, to completely automated systems—open source tools like Selenium help automate this step. Setting testing systems up can be seen as burdensome and unnecessary, but the time they save by finding bugs or identifying areas of the code that new features may have affected, may make the difference between being on-time and under budget rather than late and over budget.

Refresh scripts

With the exception of production, all of your servers will need some type of automated “environment refresh” scripts:

• In Development, these will primarily be scripts that refresh the developer’s local data store with sample data.
• In Testing, these scripts will checkout the source code and refresh the database with sample data.
• In Acceptance these scripts will check out the latest tagged code base (or a specific tag) and copy production data over from the production database.

Conclusion

Making sure your system has all the moving parts ready for your developers will make the difference between a system that works and a system that is largely ignored by your developers. In part 3, we will wrap it all up by discussing some of the downsides to implementing a full DTAP environment in your development shop.

Several times recently, I’ve discussed how architectures should be set up for development, both internal and external. This is just a primer on the subject for those curious, since it seems like a lot of people are these days. 

When it comes to developing software for PCs or the web, the structure of development environments hasn’t radically changed over the past 20 years (Note: If you are using minis or mainframes, I’m not sure any of this advice is relevant).

There are four primary systems that need to be set up and isolated. And they are described by the acronym DTAP—Development, Testing, Acceptance, and Production. One thing that has changed recently, though, is that these systems no longer have to mean separate hardware. It is acceptable to have one or more of these systems set up as virtual servers. In most cases, the important part is isolation, not performance, so having virtual servers or virtual machines on the same hardware is acceptable.

Development

In most modern systems, development is done on the individual developer’s laptop or desktop system.  This is perfectly fine, as long as proper version control systems are in place. Developers will need to have a complete, if truncated, environment. All the pieces of the system need to be part of their system. For a developer building web based applications, this means they will need, at a minimum, the following:

• The same web server used in production.
• The same database used in production. A feature- or size-limited version is acceptable for resource utilization as long as all of the features being used in the system are available.
• The same language being used in production.

Because development leads production, it is acceptable to have newer versions in development than are being deployed in production, however, because development is distributed across multiple machines,  it is important that all development be done on the same versions of all tools. Developers should be discouraged from updating to a new version until the entire development group is ready to update as well.

Your development server may also be your source code control repository. If so, it will be where unit tests are run either upon check-in or at pre-determined times.

Testing

Once the code passes its unit tests, the testing server is where integration testing takes place. On a pre-determined schedule, your testing server should—hopefully automatically—check out all the code, refresh the database and then execute a bottom-up testing script. All unit tests are run, then integration and regression testing are performed to make sure that all the pieces fit together and nothing previously working was broken.

Acceptance

The acceptance testing server should always mirror your production server in services and revision levels.  When code is ready for release, it is checked out onto the Acceptance server. Some teams re-run the integration/regression testing suite at this point also, as one final sanity check before the client sees the code. Acceptance testing for web based applications should be where your client actually sees the code and tests it using their own testing plan. 

Acceptance is also where you test your version-migration scripts.

Production

The final phase of the development process is to stage your code into production.  If all goes well, this should be a fully-automated process—or, at least, a highly automated operation. 

Conclusion

Properly setting up your environments and making sure that all your tools work together before beginning development is very important. Starting a project while implementing these procedures is a sure way to frustrate your developers and delay your project.  In Part 2, we’ll discuss the smaller moving pieces.

As part of our ongoing CodeWorks 09 Free Webcast Series, sponsored by Microsoft’s Interoperability Bridges & Labs Centers, Matthew Weier O’Phinney, Zend Framework Lead, will present a session on Object Modeling—with a focus on how it can help you create better “M” in MVC-based systems.

The webcast is completely free, but registration is required to participate live—in fact, while you’re at it, you can use our convenient registration system to sign up for all our remaining free webcasts as well, and get to experience first-hand seven more great webcasts!

The July 2009 issue of php|architect is out—this month, our editorial team has trained its collectively keen eye on the future of PHP with coverage of hot topics that will shape things to come.

Contents

Here’s a quick overview of the contents of this month’s
issue:

• Future PHP, Future Java? by Marcel Esser
  Write PHP once, run anywhere – with anything.
   
• Writing Custom PHP Extensions by Gwynne Amaya Raskind
  Sometimes, what PHP provides simply isn’t enough. But fearnot! The power of the Zend Engine has an answer. This articleexplores the basics of harnessing that power to build your own custom PHP extensions.
   
• Extending OXID eShop with Custom Modules by Vikram Vaswani
  Learn how to develop custom modules for OXID eShop CE, a GPL shopping cart system with a well-defined, extensible module API.
   
• Continuous Integration With PHP by Felix De Vliegher
  Best practices for PHP such as unit testing or documentation writing are getting more and more widespread. But how do you ensure that the unit tests are run each and every time, or that your documentation gets built? You’d need some sort of automatic process that does these tasks for you every time you integrate your piece of software within the project. This is exactly what Continuous Integration can help you with.
   
• Yii: Flex Your Flash by Jeff Winesett
  Adding a little Flash to applications is a common approach web developers take as they strive to meet today’s buzzword compliance. Maximizing interoperability and data exchange by leveraging web Services to allow application-to-application communication has revolutionized the Web business model. It’s hard to imagine the Internet today without the Web service APIs of, among many others, Google, Yahoo and Amazon. This article shows how to easily accomplish both of these modern Web development demands by using the extremely powerful and light-weight PHP framework, Yii.
   
• Enterprise PHP: Continuous Integration Background by Ivo Jansch
  Programming large systems can be challenging. Dependencies between parts of the code make it very easy to fix a feature on one side of the code base only to break something on the other. Continuous Integration is a practice that helps fight problems like this and helps improving the quality of code. Elsewhere in this issue, Felix De Vliegher has a tutorial on how to work with Continuous Integration in PHP. In this column, Ivo looks at why Continuous Integration is important. Where Felix’ article tells you how to do it, Ivo’s will show you why.
   
• Security Roundup: Trust Me – I know What I’m Doing by Arne Blankerts
  Just because you are following good security practices, does not mean you are safe. Learn where you may still be at risk.
   
• From the Cloud – Services in the Cloud by Ben Ramsey
  Need to scale your web application but finding the cost of physical services too much for your budget? Cloud services may be just the answer for you.
   
• exit(0): The Seven Seas of Insanity by Marco Tabini
  Get a glimpse into the purpose and the madness that is
  CodeWorks.

It’s been a long, hard battle, but we have finally managed to confirm and secure the locations for the New York, Washington/Baltimore and Miami locations.

• In New York, we’ll be staying at the New York Marriott at Brooklyn Bridge, a great hotel located in the heart of the Brooklyn Heights neighborhood.
   
• In the Washington/Baltimore area, we will be meeting at the Embassy Suites Old Town Alexandria Hotel, in the core of Alexandria’s historic area; the hotel is located across the street from Blue/Yellow Line/Amtrak/Virginia Rail Express station (King Street) for maximum accessibility from the entire area.
  
   
• In Miami, CW09 will take place at the  Hilton Miami Downtown Hotel, a luxurious venue right in the heart of the city.

Early-early Bird Extended to July 31st

In other (but related) news, we’re also extending our early-early-bird discounted pricing until July 31—for all our venues! Some of the CW09 stops are starting to fill-up, so now is a great occasion to secure your spot before we run out, and get into one of the best and most convenient PHP conference events of the year for as little as $99 per person!

In order to showcase local PHP talent, we’ve offered each local user group a speaking slot to fill how they see fit. Many have open CfPs going as we speak, but the deadlines are rapidly approaching. If speaking at a conference piques your interest, we highly encourage you to contact the local PHP user group in your area. You can also learn more about our involvement with local user groups by
reading Keith Casey’s blog post, or contacting us directly.

Conferences are always busy—there are people to meet, new subjects to learn, gadgets to envy, and so on. Among all the fun stuff, it’s difficult to keep track of exactly what you want to attend.

Not only that—but if you’ve been at a conference before, you know that there is a game that all attendees like to play: what shall we attend next?

Fear not! Our development team has come to your rescue with a new tool exclusive to CodeWorks 09: the DreamSchedule Generator™, which you can use to create your very own customized CodeWorks schedule.

It’s easy: pick a city, choose the talks you want to attend and give your schedule a name. Once you’re done, you can save your URL (we’ll even shorten it for you!), or tweet it directly from the convenience of the CW09 website.

What are you waiting for? Give the DreamSchedule Generator a try today!