Deployment automation provides the ability to move your software between testing and production environments by using automated processes. This leads to repeatable and reliable deployments across the software delivery cycle.
Deployment automation lets you release new features and applications more quickly and frequently, while removing the need for human intervention in application deployments.
Continuous integration/continuous delivery (CI/CD) is a method to frequently deliver applications to customers and relies on ongoing automation and continuous monitoring throughout the lifecycle, from integration and testing to delivery and deployment.
Continuous integration usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository (like GitHub or a container registry), where they can then be deployed to a live production environment by the operations team (or using deployment automation).
Once a developer’s changes to an application are merged, those changes are validated by automatically building the application and running different levels of automated testing, typically unit and integration tests, to ensure the changes haven’t broken the app.
What is continuous delivery? Learn how a CI/CD pipeline lets you to contribute to app development in an automated way:
Continuous deployment (another possible definition for "CD") can refer to using deployment automation to release a developer’s changes from the repository to production, where it is usable by customers.
Because there is no manual deployment gate at this stage of the deployment pipeline before production, continuous deployment relies heavily on well-designed test automation.
Continuous deployment through automation addresses the problem of overloading operations teams with manual processes that slow down app delivery.
It builds on the benefits of continuous integration by automating the next stage in the deployment pipeline.
CI/CD should be supported by development and operations teams working together in an agile way with either a DevOps or Site reliability engineering (SRE) approach.
Adopting agile methodologies for software development leads to faster release cycles, less downtime, and the opportunity to fix mistakes as they happen instead of waiting until after a new release.
Deployment automation doesn’t work when the development team deploys applications or configures environments one way and the operations teams deploys and configures another way.
In order for the environment to be automated it needs to be consistent. The same deployment process should be used for every environment, including your production environment.
When these teams are not in alignment you also run the risk of the operations team handling deployments manually, leading to errors, inconsistencies, and a longer release cycle.
This is why having the development and operations teams working together and following DevOps practices is so important. Your deployment automation process needs to be created by the dev and ops teams so that there is consistency and the process is repeatable.
A deployment pipeline typically follows 3 main steps (though you may also have more): build, test, deploy. This is the pipeline that supports your ability to automate the deployment process and ensures that code moves from being committed to deployment quickly.
- Build: A developer commits code to a software repository. Code changes should be integrated into environments that match the production environment.
- Test: A deployment automation tool, such as Jenkins or Ansible®, will see the new code and trigger a series of tests. Once a build has passed all of the tests, it can be released to production. Without a deployment automation process, this step happens manually.
- Deploy: In this stage the application is deployed to production and available to users.
For agile and DevOps teams, testing should occur simultaneously with development. Feedback should be passed back to the development team in a continuous manner.
Continuous integration is an important part of the development process to keep these frequent updates from conflicting with each other. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository.
You should also be able to deploy to an environment on demand. If you need put in a request for an environment to be created your process is not automated.
What's the difference between Ansible and Red Hat® Ansible Automation Platform?
Red Hat Ansible Automation Platform is a subscription product that includes all the tools needed to implement enterprise-wide automation, including playbooks, a visual dashboard, and analytics. Ansible Automation Platform allows you to consistently deploy multi-tier applications, configure services, and push application artifacts—all with one common framework.
Ansible Playbooks—written in human-readable YAML—describe the desired state of your systems, which are usually kept in source control. Ansible Automation Platform does the work of getting your systems to the desired state, no matter their current state. Ansible Playbooks can make your installations, upgrades, and day-to-day management repeatable and reliable.
Enterprises need the ability to easily create automation, but also to share and reuse automation across projects and teams with the right level of governance and control. With Ansible Automation Platform, you can deploy new applications and services faster, manage IT infrastructure more efficiently, and increase productivity in app development.
How much time can automation save you?
Answer a few short questions to find out how much time you could save by using Ansible Automation Platform across your organization.