This is a good subject for a meditation. I think that the answers to the questions you pose depend on the environment that one is producing code in.

Backing off just a bit, what does production quality mean?

To my way of thinking, production quality "anything" means that the process for generating whatever it is you are producing is clearly defined. What the process consists of may vary from place to place, but when your product hits production, it had better have had a pre-defined process to flow through.

This may be tangential, but I will toss it out there anyway. "Production" is a strange term for me when it comes to software. In the solid world of widgets where I come from, a given product may spend anywhere from three months to ten years in "development". The development phase determines things like the materials that are going to be used, the equipment which will be needed to process those materials, methods of quality control... etc... . When you get to "Production", what you have is a clearly defined process which is intended to produce the product(widget), usually in some comparatively large number, with high yields and at least some margin of profitability.

Software on the other hand, spends most of its time in "development". After which it is deployed once, then bug fixed and maintained, and updated. A massive development effort for a single one-time product. Ok, maybe that is mostly just semantics, but not entirely. When software hits "production", it is in the end users hands, not the manufacturers hands. In overly simplistic terms, other than the maintenance, the life cycle is complete. Generally, we only make one! That is weird to me because it is the development that we have to develop processes for.

Back to the matter at hand..., (sorry for the divergence).

A good deployment means that:

• All testing is complete per the afore-mentioned process
• The environment that is being deployed to is well defined
• It is known how the deployable unit(s) is/are expected to impact the environment.
• The right people are on hand at deployment time.
• Communication channels have been established between those people
• Backout plan is reasonable.
• What constitutes the need for a backout and who makes that call has been established
• ... lots more
• oh yeah, did I mention that there are checks in place to document that the development process has been followed?

On the other hand a good deployment can also mean that I scp'ed the script to the user, and he/she uses it from now until they retire.

It is all process.