Dr. Dobb's Journal - September 2008 - (Page 30)

d09ryla_p2as 7/14/08 8:39 AM Page 30 Core Technology BUILDING A ROBUST DEVELOPMENT ENVIRONMENT follow. Once the branch is created, someone must be responsible for it. Project leads fit this role best; they can merge changes from the trunk into their branch on a regular basis, or delegate the task to another member on their team. Delegating these responsibilities helps the development team feel ownership over the source code and process. Handling Change In the Platform Changes in your core platform are inevitable over time, but they don’t have to be “harbingers of doom.” Making the change a success, for the team and your build process, comes down to how you decide to handle the change. For instance, you may decide to pass up a couple of point releases of the .NET Framework (or Java JDK) to avoid instability or new engineering hours in the build process. Gauge how this sits with other stakeholders. Are they disappointed? Does skipping this upgrade hold up their development roadmap? Are they angry? These are activities that can’t be settled easily via e-mail and require face-to-face interaction. Be proactive about gathering these details because the effect can be significant. A platform upgrade in my environment from the .NET 1.1 Framework to the .NET 3.5 Framework was planned over a number of related product releases, with the first release still on .NET 1.1. This can feel like shell shock to those responsible for the build and source management. Two versions of the source must be maintained for a period of time without interfering with each other and be built with different compilers. To accomplish this, create a new branch from your source code’s trunk for the first release. Then upgrade the trunk source code to the targeted platform version. You can now place one team on the old version and another team on the upgraded version. Once the release on the old version is complete, you can reverse merge those changes back into the trunk (see Figure 4). Be careful not to perform the platform upgrade on a development branch; that is, an open invitation to branch on a branch, which gets unruly quickly and is always best avoided. The branch -> upgrade -> release -> merge process is a prime example of the branch Figure 3: Multiple branches in isolation. workhorse of the team. Making the build fast, concise, and as useful as possible changes opinions dramatically. The CCNET server deployed here used NANT scripts to generate a unique version number embedded in each compiled component. The version number is also used to label the source code after a build and provides traceability of the component all the way to production. After the compile and other tasks, the artifacts are deployed to a predetermined environment. This way, the process is automated, repeatable, and consistent. Take advantage of this kind of infrastructure to add value beyond a compile and deploy. You should also follow a deployment methodology where branches are not candidates for release. Any given branch must be merged back into the Trunk for integration, be approved, and then have an additional release branch created for it. This creates an additional level of isolation—this time between your testing environment and your development environment. Following these strategies puts you in a good place to move toward true CI if and when the time occurs. Always think long term with these decisions; they form the bedrock for development activities. 30 Automate Again, the build process is more than compiling source code. There are other activities that need to occur to test and use the newly built software. These activities are usually domain specific—perhaps triggering a series of unit tests or starting a system stress test. In my case, a web environment with Microsoft IIS 6 is created for each branch. The ability to quickly build out an environment for a developer or testing server can free precious cycles from your team. Spending time creating a tool to accomplish this yielded big results. The tool can setup the IIS website on any server identical to production. Then, spinning up a new environment is as simple and repeatable as compiling the software that executes in the environment. Are there items in your test environment that are difficult to reproduce? Are developers ever held up changing configurations? Look for opportunities like these to automate as much as possible. Delegate Responsibility Branching is considered an administrative task and should only be done with team or management agreement. Small checks and balances here prevent bloating of branches and give the development team a signpost to Dr. Dobb’s Journal l www.ddj.com l September 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - September 2008

Dr. Dobb's Journal - September 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation With Erik Demaine Application Lifecycle Management Meets Model-Driven Development Building a Robust Development Environment Real Users Really Matter Matching Wildcards: An Algorithm The Android Mobile Phone Platform Managing Application Thread Use Signalling Integer Overflows in Java .NET Development & the IBM WebSphere Portal Server The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.