There's a reason the definition starts with safety... safety first! Groan. Sorry. Seriously, Continuous Deployment is first and foremost about providing a safety net so that code can be deployed without painful accidents. Deploying automatically sounds incredibly stressful but the reality is that deployment stops becoming stressful. When you're deploying without injury several times a day, deploying actually becomes soothing! It's the undeployed code that feels stressful, because undeployed code might not work in production and might need to be rewritten. Deployment becomes business as usual—forgettable even. Safety is not a priority, it's a prerequisite.
The testing and deploy pipeline must be both fully automated and automatically triggered on commit. Your code must go through a gauntlet of automated testing on every commit and then must be pushed live. Every change must be committed together with its automated test coverage. For the web you should target five to fifteen minutes from commit to live in production. For other platforms you may have to completely rearchitect your application to realize those speeds, but in the meantime you can still have automatic but less frequent (daily or weekly) deployment and reap many of the benefits of Continuous Deployment. Every commit should be deployable and no human should be involved in picking which revision to deploy.
To deploy to production is to update your production environment's code. Nothing more. Traditionally, deploying code and releasing features were intimately tied together. Deployment is not release. Under Continuous Deployment releasing a feature becomes something controlled by feature toggles in the software, driven by domain requirements and guided by stakeholders. Even small features will end up being multiple deployments. Continuous Deployment doesn't mean every half-baked feature is released instantly; it means every feature is released to exactly who you want and exactly when you want. Product managers can safely release the feature themselves.
Continuous Deployment requires frequent small commits. Every developer is checking their changes in to master at least every day. No batching beyond a day. No branching. No really, no branching! Code in a branch is risky and gets riskier and more expensive the longer it stays off of trunk and undeployed. Specifically it's "no long-lived branches" but under Continous Deployment a long-lived branch is anything over a day, and at that point almost every branch is long-lived. This shouldn't be controversial. This isn't even Continuous Deployment. This is just your standard Kent Beck Approved Continuous Integration (TM)!