Section 5.1. Requirements | Mongrel. Serving, Deploying, and Extending Your Ruby Applications

5.1. Requirements

You will not do this in a day. If you are expecting to code until 1 minute before your deadline and then simply point and click and have an instant server then you need to take some kind of medication because you are violently hallucinating. You will need at least a week of 8 hours days to make sure your first deployment works and to have the time to do it right.

Yes, that's right, 40 hours minimum. If you have no Unix system administration experience and no network administration experience then hire someone on a consulting basis and expect them to still take this long. Why would an expert take as long as a beginner? Because they don't know the particular brand of dumbass at your company. Harsh, but it's true. If they're good, they might do it in 20 hours, and if you're good, then an expert can do it in three. If you've done your first deployment in less than that, then you must be forgetting all the time you spent fixing it later.

Because of the wildly differing nature of all the various operating systems possible, we have to gloss over the actual installation of software. We will list any gotchas we or our reviewers found for the various systems, but it's up to you to use your system's package installation method.

5.1.1. Required System Access

This is important enough to merit its own subsection. If you do not have sudo or root access to all of these machines, then don't bother continuing. It is possible to install everything to an unprivileged directory, but that is a major piece of work and isn't worth the trouble.

5.1.2. Best Practices Rubric

A best practice is most easily defined as "Whatever is working consistently for everyone else." Your first production deployment is not the time to become clever. What you want to do is adopt some common best practices, but since this short cut doesn't have the space to tell you what those are, we'll give you a little rubric to see if you're ready.

Does your application have full unit testing?
Are you doing automated daily deployments to a staging server?
Does your planned production deployment have agreement from everyone that it should go out?
Do you have either a QA team that can test it or automated "interaction tests" with a tool such as Watir or Selenium?
Do you already have the hardware installed, configured with your chosen OS, and networked properly?
Have you tested that the network is configured correctly and fast enough for your deployment?
Do you have the proper amount of RAM and disk for your deployment?
Is Ruby installed on all machines such that it can build Mongrel properly?
Is there a dedicated person whose sole responsibility is building and maintaining the production deployment?
Does this person have a dedicated developer to help or is he already a developer familiar with the code?
Do you have a shared location where you can document the deployment, such as a Wiki or CMS?
Do you know how to use httperf or ab and know what the statistics mean?
Are you using Rails migrations for all of your database changes and have scripted anything that migrations can't do?

For each question you answer with "NO," add 10 hours to your time estimate for completion. This may seem unrealistic, since saying "NO" to everything means it'll take 190 hours (about one month), but this estimate is actually low according to most first deployment experiences. What we've found is that without all these things in place, you end up doing a poor deployment and spend the next month fixing it up.

If you're just starting out and can't answer these questions properly, then consider these as instructions for what you need to do for a good development and staging setup. Go through the pains of getting to "YES" for each of these questions in your staging setup and then do your production deployment.

5.1.3. Worst Practices

Zed Sez

Programmers recently had a major shift in their quality focus with the introduction of best practices from the Agile methodologies and the Capability Maturity Model. These days if you aren't doing continuous integration, writing solid unit tests, performing personal process improvement, frequently communicating with your team, and automating everything, then you are easily labeled an amateur developer.

Nothing like this has happened for system administrators. I'm not quite sure how this half of the IT industry gets away with it, but my experience has been that system administrators are far behind in their quality practices compared to developers. They frequently do things by hand, never measure the quality of their systems, are constantly making unilateral changes that impact the company, and frequently make policy decisions in the name of "security." Usually these "security" policies only make their unautomated job easier rather than actually improve security.^[4]

^[4] I worked at a government agency that said HTTPS+XML was not secure, but that SOAP was, and used telnet to manage important records based on system administrators setting policies. If the irony is not obvious (lucky you, you've never had to deal with SOAP), SOAP is HTTP(S)+XML, and telnet sends in cleartext.

Sure, developers screw up too, but today developers who haven't adopted many quality practices are ridiculed and laughed at by their peers. Nobody questions why a developer can build, test, deploy, and validate an entire product with one script, yet a system administrator has to spend two hours typing to do simple things like change passwords.

If you're a system administrator, the best advice I can give is "Automate or die." I firmly believe that 99% of what system administrators do can be automated since I've done just that everywhere I've worked. Watch out because there's money in wiping you out with automation. It just takes one good book written by the Kent Beck of system administration and you're out of a job.

If you're a system administrator and you're offended by this, then answer this question: "Could you not run ssh for a week?" No, I don't mean write a script named "flabber" that just runs ssh. I mean is your administration automated to the point that you don't need to ssh manually into your machines for weeks on end? If you log in hourly or even daily, then you are part of the problem. You have no right to be offended.

The following list of "worst practices" is for both developers and system administrators, but it's more for system administrators since they'll be doing the deployments. I've done all of these at some point, but I don't do them anymore.

Creating and maintaining unversioned files.
Doing config changes on production, manually rather than through the automated deploy process
Not telling everyone you're making changes.
Deploying without telling anyone.
No strict development, staging, production-automated maintenance process.
No production rollout-approval process.
Not indicating which changes are going into production.
Not following best practices (you are not smarter than I am).
Not following the same process for dev, staging, and prod every time.
Letting anyone deploy to production.
Not letting anyone deploy to development.
Preventing developers from controlling staging and development.
Not collaborating on the staging deployment so they know what's going on.
Not documenting their systems and deployment methods.
Not tracking quality of service to identify production problems and proactively prevent them.
Not automating everything done to any production system.
Using substandard tools because they are either free or commercial (people should use the best tool, not the one with the most CYA^[5] factor).
^[5] Cover Your Ass

If you do any of this, then stop now. You are not helping, and it's just going to add even more problems in the future. I would say if you do any of the above practices, add another 10 hours for each practice.