There’s something to be said for smaller groups. Around 10 of us had some great discussion about developing efficient processes to move builds from dev to test to prod and about an architect’s responsibility for code quality. Leon Gersing, Mike Levy, Mike Wood, Maggie Longshore, Nino Benvenuti, and some others talked around the table, fishbowl style, at Max Training in Mason.

A quick note about future meetings. The new date will be the 3rd Thursday of each month as Max is consolidating user groups to Thursday evenings. So check the dates of your favorite group. Chances are the date has changed. CINNUG, by far the largest group to meet at Max, is the only exception as it will keep the 4th Tuesday of the month schedule.

I gotta get some exciting announcements out of the way. The 10/28 CINNUG will feature ineta speaker, Matt Casto, talking about controls in Silverlight 2.0 (yeah, I’m publishing on 10/29 – it was a great presentation, though). The 11/25 CINNUG will be the culmination of the membership drive and you’ll want to be there to hook some awesome swag. We’re giving away an xbox 360, a 1-year subscription to Safari Books online, and 1 MSDN premium subscription valued at $10,000 that includes VSTS. You have to be present to win. You get one entry in the give aways for each meeting you attend and for each new friend that comes with you. So you still have Oct CINNUG, Nov CinArc, and Nov CINNUG to earn entries. Bring some people with you.

November 17th will feature a CINNUG special meeting (and, yes, it counts towards entries in the giveaway) where Microsoft’s Mark Mydland will present on VSTS Tester edition. Mark manages the development and QA teams responsible for Visual Studio Team System for Software Testers, and he’ll take us on a deep dive of what to expect in future releases. 6PM at Max Training.

Other odds-n-ends include the next MSDN event on 11/5 that will cover SQL Server 2008. PCD keynotes will stream live this year. Expect announcements and unveiling of Microsoft’s implementations of cloud computing, Oslo, and distributed computing.

Back to CinArc. Our first topic was the process for moving builds from dev to test to prod efficiently. The notes are in raw form below for those who are interested in following along. I’m way behind on posting, and I didn’t have a lot of time to make it all nice and pretty. You can thank Matt Brewer for a great job on the notes.

Creating/Designing Dev-Test-Prod Environments – Handling the differences (Mike Wood)

Topic Synopsis:

• How do you architect a solution to ease the transition of code artifacts between dev-test-prod environments?
• How do you handle the differences between these environments?

I’m already late on getting this out, so here’s a raw dump of the notes.

Creating/Designing Dev-Test-Prod Environments – Handling the differences

Topic Synopsis:

• How do you architect a solution to ease the transition of code artifacts between dev-test-prod environments?
• How do you handle the differences between these environments?

Discussion:

• Are Web Apps the answer? Helped to take five deployment steps down to one
• How to handle Test and Prod when dealing with outsourced/offshored development shops? Hard to prevent code churn.
• Is there an inherent policy problem?
• Try to get as close to a “click-to-deploy” as possible via automation
• Change management Red Tape – grows over time
  • Find an external partner to help define the process – Helps keep politics to a minimum.
• There is a perception that Change Management process provides throttling which in turn produces quality. “It takes time to do things right”
• Communication is key
  • Project Management -> Change Management
  • Processes need to align
• Projects need to bake in time
• If following an Agile approach –
  • Start to invite the operations folks to stand up when sprint is 75% complete.
  • This gives them time to start on your infrastructure needs
• Know how to correctly test before moving environments
• The solutions architect must act as a “Broker” in the process

Key Conclusions:

· Baking in project time to do the change management function

· Communication with operations

· Involving the right people in the project at the right time

o E.g. Inviting Ops to daily scrums at a certain time in the sprint

Moderators Note: This topic obviously went off course from Mike’s original intent. We talked more about the process of change management slowing down time to market than how to architect system to move across environments easily.

Architects Managing Code Quality

Topic Synopsis:

• Is Quality a last priority?
• Where does Quality fit in the software development lifecycle?
• Quality as defined by Leon: Reducing Cyclomatic Complexity, Following good OO principles (SOLID)
  • It is not just following coding standards

Discussion:

• Code Reviews with everyone involved
  • Maintain a wiki of the reviews
  • Frequency: once a week starting out, taper off over time to specified intervals – be consistent
• How do you fight the “If it runs, it’s good enough” mentality?
• Code review need to be done on everything – including patches
• There needs to be leads (architects) that are constantly training/retraining devs on the process
• Book from Parasoft CEO (link needed)
• Creating a culture of shared responsibility for quality
  • Lean Manufacturing – “Pulling the Rope”
• Having the proper tooling for a team code review is very important
  • Helps streamline the process
• Explicitly ranking quality
  • Where does quality fall in the Time – Features – Cost triangle?

Key Conclusions:

· Quality is fostered through a process of code reviews with architects at the lead

· Everyone on the team must be involved review the code

· Collective ownership of code helps to drive quality

Mike had a number of great reads to give away including

The Enterprise and Scrum

I. M. Wright’s Hard Code (Best Practices)

- Andy