For Publishing Sites you'll usually have
- an authoring environment (in the company internal network) and a
- a production environment (in the company DMZ or protected by a reverse proxy like ISA, ForeFront, ...)
Content Deployment jobs are a native SharePoint functionnality that allows to move (published / see it as a major version list item) content from an environment A to environment B. This is extremely handy when you need to work on the same content but deploy it on different network location (inside / outside DMZ) with their own security policies (eg: no write access at all in production). Please note that both environment must have the same SharePoint version (patching includes) and that you must ensure your target web apps are clean, the same solutions are deployed on both farms, etc.
I've delivered publishing solutions for a few companies that also have an internal review farm (with content deployment scheduled at a higher frequency than on the production site), this review-only farm is used as a starting point to provision the final production farm. This is handy when the content needs to follow complex approval before beeing online without testing it in production to ensure it's as expected. (was like that in all banking scenarios I encountered).
Content copy between environments is never instantaneous (even with the quick content deployment process, it's scheduled).
On the opposite road, nothing prevent you from having a single environment on your production site and rely on the native approval workflow to let the contributor work, approvers do their job and have a production view (as seen by the visitors) different than what the contributors might have. I do like the simple approval switches on the library instead of a workflow (they will ask someone to approve but will not trigger a complete workflow. It's more like an additional protection than a complete approval workflow). You could even have content deployment within a single farm to a separate web application that would be targeted to your final audience while the authoring one would be restricted to internal contributors.
In all scenarios and outside the network boundaries (eg: how you will trim the access on your DMZ, etc.) you'll configure the farm the same way in all environment (same service) and the content deployment are native functionnalites (they have their own entries on central administration). You need to make sure that both farms can communicate between them obviously (SharePoint will either use SQL Snapshot or Web Services with export package (.cab) to transfer content)
In 2013, there is a big shift in the Publishing Process with the availability of the Content Catalog functionnality and the associated cross site publishing (http://technet.microsoft.com/en-us/sharepoint/jj872721.aspx) which might be handy to investigate / prototype if you rely on centralized content.
Best Practices wise, anything from Waldek is gold but I guess you already know that. Publishing best practices is a wide topic but you'll need to ensure overall performance (implement a publishing cache profile or rely on the content catalog as this one is relying on search which make content retrieval a snap), implement SEO but in SharePoint 2013, all the hard work that we had to do in SP2010 is available at sight (xml sitemap, seo properties, keywords, clean url through MMS navigation, etc.). In this kind of scenario, make sure that you stress test your target farm (will it handle the load), and as usual in SharePoint, your farm is clean, up-to-date and optimized (all uneeded services de-activated, SQL Server is fine-tuned and rely on RBS for large media content, minimize the number of Web Application & Application Pools, implement blob cache, etc.).
Publishing sites will benefit from the same optimizations and operations you would do for any SharePoint implementation / solution.
Hope it helps !
Edit : and for SP2013, make sure you read this case study : http://www.microsoft.com/en-us/download/details.aspx?id=35592&ocid=aff-n-we-loc--ITPRO40936&WT.mc_id=aff-n-we-loc--ITPRO40936 :)
