The idea is to shorten the way to production
There is a new approach. First we deploy something (a template) and then we build something
Continuous Delivery in a Nutshell
Continuous Delivery allows us to deploy to your live server. The aim is to reduce risk and manual intervention. Continuous Integration refers to the test-driven development part of this process. That said, the two terms are often used interchangeably.
Continuous Delivery can be imagined as a deployment pipeline through which software flows from developers to the live server. The flow can be stemmed if any person or system notices a critical error. The process generally follows these steps although policies will differ from team to team:
- Writing code and automated software tests.
- Developers merge their changes to a central version control repository.
- The Continuous Delivery system builds and executes automated tests on a staging machine. Developers are notified if any failures occur.
- Additional user acceptance tests are performed on the staging server.
- On final approval, all changes are deployed to the live server.
Continuous Delivery is often used in agile development environments but you can adopt it regardless of the processes you use. The process comes with a host of benefits:
- The deployment process is robust. You’ll have confidence that an update will work before it’s installed on the live server.
- There are fewer risks. The process is less prone to human error and, in the event of catastrophic failure, you can roll back the application to a working state.
- Quality control is maintained. Only approved code should be put live.
- Your team becomes more productive and development costs are reduced. The initial set-up time investment will be repaid within a matter of days now that developers do not need to be involved in manual deployment processes.
But the benefits of Continuous Delivery are significantly greater when you don’t need to manage the software yourself.
