How can we improve our deployment and build systems?

If you feel good, you could become your company's Continuous Integration Champion . You can do some research on a good CI process with TFS , write a proposed solution, evangelize it to your fellow developers and direct managers, revise it with input, and pass it on to management. Or you could just sit and do nothing.

I've been in management for a long time. I always appreciate someone who identifies a problem and offers a well thought out solution.

One of the most important parts of using TAGS is that you can rollback to a specific point in time. Think of it as backing up images. If something bad is deployed, you can safely assume that you can revert to a previous working version.

Plus, developers can quickly grab TAGs (dev, prod or whatever) and deploy them to their development PC ... a feature I use all the time to debug production problems.

So, you need someone to tell other developers that they should tag their code every time a build is done and increment the version counter. Why can't you do this?

You also need to inform management that you believe that the level of testing performed is insufficient. This is not a unique problem for the organization and they will probably say they already know. It is not worth mentioning this, and not waiting for a serious problem.

As far as people who do builds or automated build processes go, it depends on whether you really need it based on how many developers there are and how often you build.

What is the problem? As you said, you cannot tell if the management sees the problem. Maybe they don't! Tell them what you see as the current problem and that you would recommend fixing the problem. The problem stems from the fact that "our current process has failed 3 times 10 times, and implementing this new process would reduce these failures to 1 in 10 times."

Management must see improvements in terms of: lower costs, higher profits, less time, less resource use. “Because he made extensive use of best practices” would not be enough. Neither, "because it makes my job easier."

Management is often unaware of the problem because everyone is too afraid to say something or thinks they can't help but see the problem. But your world is a different world than theirs.

I see at least two big problems: 1) Developers upload changes themselves. All changes must come from source control. Are you seeing times when someone made a change that went into production but never made it to the original control and then accidentally deleted on the next deployment? How much time (money) was spent trying to figure out what went wrong?

2) Lack of a clear promotion model. You guys seem to be changing changes between environments rather than "building". The main difference is that if two changes work great in UAT because of the way they interact, if only one change is progressing to production it might break there. Promoting consistent code - whether by labeling it or simply zipping the entire web app and promoting the zip file - should be less of a problem.

I am working on a continuous integration and deployment solution , AnthillPro . The way we address this with TFS is to get a new code from TFS based on the date stamp (when someone clicked the put on stage button).

This gives you the most (all?) Traceability that you could use with tags without having to bypass the tags. The system simply records the timestamp, and every push of the code through the test environments is tied to a known snapshot of the code. We also have clients who install tags as part of the build process. As the first poster said - CI is a good thing - less work, more traceability.