I ask this, because I am not an “experienced” developer, however I do have experience in automating builds, setting up automated deployments, including Unit Tests Suites within our build process, Creating JavaDocs, Including Coverage Reports, and Creating scripts to automatically deploy (the same EAR file) to each of our environments, only including new configuration files to our deployment process.

Many people would say that this is configuration management, however I would argue that this is software engineering, not including development as a subsystem/process of software engineering.

I also have read the majority of this book. It is awesome. How would one market themselves, if they are well versed and has experience with the efforts detailed in this book, given that many wouldn’t consider this work software engineering?

Thanks very much for your feedback and your appreciation.

I hope the problem you mention is one of terminology rather than emphasis, because I certainly agree with you. In retrospect we certainly could have made our choice of terminology clearer. Throughout the book, we’ve used the term “deployment” to mean what you call “release”. In the book, “release” is used to mean “release to users” which, if you manage your own production environment (as opposed to shipping CDs or hardware devices, say) is also “release to production environment”.

We do emphasize, in chapter 5, that one of the core principles of the deployment pipeline is “deploy the same way to every environment”. We expand on this throughout chapter 10, where in the first paragraph we state that “When deployment to production occurs, the same process should be followed as for any other deployment.”

Having said that, it’s probably impossible to overstate this point.

plus another DCVS on page 398.

my apologies for using your blog comments for this, just couldn’t find another way to get in touch.

I just wanted to say that I appreciate the material you’re publishing and all of the hard work that goes into it.

The premise of “continuous” and “automation” go hand in hand and represent a series of best practices that seem to have been lost during the Dot.Com boom, when the industry would hire anyone and everyone that could fog a mirror, say the word “technology,” and spell “HTML”.

My only recommendation is that you clearly specify and stress that the movement of code from any one environment to another is a Release (and therefore the practice of it), in and of itself. For example:

* Release to Common Build Environment
* Release to Integration Testing Environment
* Release to User Acceptance Testing Environment
* Release to Education Environment
* Release to Production Environment
* Release to Disaster Recovery Environment
* Etc.

I’m glad to see that you’re taking the time to push solid best practices and I wish you continued success in these endeavors. They can only help the industry.

My Best,

Frank Guerino
Chairman
The International Foundation for Information Technology (IF4IT)