Continuous Deployment is a software development practice in which every code change goes through the entire pipeline and is put into production, automatically, resulting in many production deployments every day.

With Continuous Delivery your software is always release-ready, yet the timing of when to push it into production is a business decision, and so the final deployment is a manual step. With Continuous Deployment, any updated working version of the application is automatically pushed to production. Continuous Deployment mandates Continuous Delivery, but the opposite is not required.
Regardless of what your end-goal is, and where you are on your DevOps implementation journey, both Continuous Deployment require automating your deployments and Application Release pipeline.

The benefits of deploy automation are:

• Deployment modeling controls variability and reduces errors, resulting in higher product quality
• Automated and accelerated product release processes lead to on-time and frequent product releases
• Consolidated access to all tools, process and resource data leads to faster troubleshooting and TTM
• Effective collaboration between Dev, QA, and Ops teams leads to higher quality and higher customer satisfaction
• Centralized view of all deployment activities and outcomes leads to faster and lower effort audits

How Cotocus Will help -
1. Use an issue tracker for everything
For every development task – bug, feature request, whatever – we create a unique issue to track it. Long running projects have an “epic” issue that all the discrete task issues link to.
2. Create a separate branch for this work, tagged with the issue number
In your version control system, will create a branch which contains the issue number and a short description of the change.
3. Develop on your branch, including continuous integration
Few tools will allow you to easily make many commits on a branch, and then only merge when ready. But that doesn’t mean we will skimp on continuous integration. We will run our full integration test suite against every commit on all active branches.
4. When ready, create a pull request for the branch
We will create pull request, which is DVCS world’s version of code review. Inexperienced developers tend to dislike the idea, but many experienced developers love them, as they provide a safety net when working on critical code and infrastructure.
5. Merge and package as a release
Once the pull request has passed, the merge to the release branch can be performed. At this point, we perform full release of the software.
6. Deploy to staging
Because we’re talking about continuous deployment, this stage is also fully automated. Building a released version of the software triggers an automatic deployment to our pre-production staging servers. This allows additional QA to be performed on it, and possible review by customers or other interested parties.
7. Promote to production
One of our rules is that we never push builds directly out to production. The binaries that go to production must first go through QA on our staging servers. Thus, we don’t so much “release” to production as “promote” once we’re happy with the quality.

A note about continuous deployment tools

• JIRA Software for issue tracking
• Git for version control
• Bitbucket for repository management
• Bamboo for build, test, and deploy automation
• Ansible for cross-host coordination
• Nagios for monitoring

Offers
Training - We walk you through the technical practices, necessary tools and customized application of an enterprise Continuous Deployment program. Students will learn about workflow integration through hands-on labs, class demos, class participation exercises, video tutorials and traditional slides and lecture. The class is highly interactive, encouraging individuals to fully participate in all exercises to retain maximum benefits of the learning.