If it changes together, it gets built together

The title pretty well says it all.  If changes in two or more components or subsystems can affect or break the other, you better get yourself a comprehensive automated build of some kind that exercises the integration of the two.  In particular, and my hot button issue for the day, make database changes and code changes go through the same build and configuration management.  Like it or not, a database and its application are most likely going to be strongly coupled.  If you're writing new code that requires database changes, you really, really need both sets of changes to hit the code trunk at the same time.

 

Thank you for listening, I feel better now.

- Roy Moore 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Continuous Integration, Maintainability. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://blog.eriklane.com Erik Lane

    Tell me about it. I hate getting ‘one-off’ versions of components for the needed changes and wait until their component gets updated before I can check-in so I don’t break the build….There has to be a better way!

  • Colin Kershaw

    It’s funny, this idea seems so last millenium, yet – like so many good, basic ideas – it still is something that’s not broadly adopted or even accepted.