How can I avoid the pitfalls that pass the finished product to the installation team?

Question

Does anyone have experience transferring the finished product to the installation team?

Our product is installed via RPM, but also requires copying some MySQL data, changing some configuration files, and running several written development scripts. The presence of the installation team is wonderful, but it is a development that works on call, and after each installation we receive calls from the client through the hours that we must support.

We learn from every incident, but it would be helpful if our clients, our reputation and my sleep are more active.

In particular:

• What tools did you use to improve communication / collaboration between teams?
• What technical solutions did you use?
• What policies have you used?
• Has anyone been successful with writing validation tools after installation?

Edit: I have to clarify that I'm not talking about software failures that should have developed in development and / or QA. The problem is that the client says that “Option A is unavailable suddenly” because it is not configured to turn on or “I cannot log in” because the authentication server is not configured correctly.

Answer 1

This is basically Assaf's answer with a different emphasis. There are two main elements on both sides of the deployment: ENSURE good deployment.

---

• Some moving parts

This means that if you have the opportunity to provide several files and install them in specific folders in the working environment, or you can pre-place the files in the folder structure and ask them to simply copy it to the root. Or even easier, a batch file. Or MSI. If they need to run SQL scripts, then clearly show where they are.

Basically, this step boils down to the fact that the developer can create scripts and batch files and automate as much as humanly (heh). Thus, the developer (who does not know how the application, and you as well) is not expected to think about what they should do with the three remaining files. (Spirit, you have to put them in folders A, B, D and ZZ)

---

2. ACCOMMODATION GUIDE

This is all in hats because it is superior to the first step. I am talking about a VERY thorough guide.

Can't say

"move the files associated with the Map to the Map-App-Data folder."

He must say

"* Move the x, y, z files (located in the X folder in your deployment package) to the Map-App-Data folder (located in D: \ AppName \ Map-App-Data) *".

Go through the motions, even saying “Remote in to X server, and then y,” because you might think that he knows which server the deployer should be installed on, but for multi-server settings it can be pretty sticky as to what should be do where. Given the document, this circumstance means that anyone can deploy, even one who you did not have the opportunity to train about what is happening.

---

2.1 Rollback Plan

Place the rollback plan directly in the deployment guide. If the deployment goes wrong, and sometimes they will, you do not want to leave the server offline until the deployer can wake someone who knows what is going on. He should be there right in front of them. Even if it seems obvious and simple to you, remember that you spent the last four weeks on this project, and this person spent the last 20 minutes. They simply cannot be expelled to know that you are not telling them.

---

2.2 Check Deployment Guide

Go through the steps yourself. Or even better, ask a colleague who is NOT involved in the project to try installing it in the UAT with your guide, and you are sitting next to them. Anywhere they are wrong, change the manual. In any case, the deployment is going wrong (the situations that you saw earlier) add a footnote in the guide explaining why this situation arises and how to fix it, if possible. It is imperative that there are no errors in your deployment guide, because when you write a deployment guide, you basically do the deployment (because you know how) and you get the bonus of sleeping through it. But it also means that you have all the mistakes.

Please add comments to everything that I missed and I will toss it.

Answer 2

It was not intended for your specific questions, but once and for all there was a team of developers and testers who deployed a web application for a set of servers for testing and verification.

When the time came for the release, the client received the files for deployment and deployed them according to the specifications ... For a set of servers, nothing looked like our development servers.

There was a massive influx of errors, chaos ensued, the client raged, and the poor developers did not sleep.

My advice is one of the most obvious; Ensure that the development environment matches the production environment to avoid environmental errors.

Answer 3

Yes. Some basic rules:

• Always ship a product signed and sealed. Use zip (or anything that has a checksum), do not deliver individual files or directories.
• Burn it to a CD and physically transfer it. This way you will find out that you have a copy (and backup) that works. You would be surprised at how easy it is to screw up the installation because of CDs that corrupt files silently.
• The installation command (or QA) should receive exactly what the client receives, no less. Suppose they know less about your product than the dumbest customer.
• Naturally, you should always keep a repository of all such deliveries, cataloged by version.
• Print any installation / deployment / manual that comes with the version and physically transmit it. Like paper. Even if the document has not changed from the latest version. I spent a lot of time helping QA debug the installation, and later realizing that they were using the wrong installation guide.

Answer 4

• You do not have an “install command”. Developers should be responsible for developing a working system, not for the piece of pieces that they throw through the wall for some other weak juices to work.

• Fully automated deployment / upgrade process. Deployment should not require manual decisions because someone will one day mistakenly make the wrong decision.

• If the deployment fails, correct the automation and republishing. Do not put the system in production on the spot because people once forget to check for corrections in the source code repository.

• Check the deployment / upgrade process regularly during development. Preferably at every fix, as part of a continuous integration process.

• Make sure the test environment is as close to production as possible. Ideally, the only difference should be passwords.

• Run the test environment as part of the deployment. I usually implement them in the system itself so that it self-tests and reports what is wrong with its runtime.

• Simplify failover deployments.

Answer 5

After some discussion, our development team came up with something called Jump Start. We can pack our RPMs and any necessary configuration (MySQL commands, changes to httpd.conf, etc.). When we encounter an installation problem, we can change the script; this largely ensures that the same mistake will not be made twice.

I will update as soon as we start using this live.