Before we define what is needed for a production-like host, let's analyze what we have covered so far:

• We can effectively run and maintain Jenkins.
• We can evaluate what to consider and what to avoid when setting up plugins.
• We can recognize what it takes to have successful server updates and upgrades.
• We can avoid host downtime by following best practices.

Production servers are usually client facing, or in simpler words, web pages that end users actively interact with. Normally, in order to affect a proper production environment, changes need to go through a few more environments for testing and quality assurance. Here are a few examples:

The pages facebook.com or twitter.com are both production sites. Why is this? Because these are pages that users open to interact with their products.

Their staging environments could be, for example, staging.facebook.com or staging.twitter.com. End users won't have access to these, because this is where final changes are tested before they appear on the production sites, for example, new user interface features.

In our case, we wouldn't need a staging, QA, or test Jenkins environment. This is also because Jenkins ensures that the right features and integrations get to production and other environments, and thus this is a production environment itself and the
center of all other operations.

A few best practices mentioned on the Jenkins wiki for production environments include the following:

• Security
• Access limited to the master node (we shall delve deeper into this later in the book)
• Backup of Jenkins Home
• Project naming conventions should be followed
• Getting rid of jobs and resources that are not in use