As development teams adopted Lean and Agile methods, they often became capable of producing production-ready software on a daily basis, or even more frequently. But managing software in production environments was traditionally the job of operations, not of the developers. And operations viewed its job as slowing the pace of releases, because releases meant bugs, crashes, and other problems operations had to handle.
How could this gulf between development and operations be narrowed? Operations itself had to become Lean and Agile! In particular, rather than hand-provisioning operations infrastructure, operations team members had to themselves become coders, and apply the full toolkit of Lean and Agile methods to operations: incremental changes, automated testing, source code control, automated builds, and so on. One of those operations people, Patrick Debois, named a conference DevOpsDays, and from that seed, the term "DevOps" spread.
Completing and delivering small batches of work at a time is such an important part of DevOps that we could almost say that every other part of DevOps exists to enable frequent, reliable delivery of small improvements to a piece of software.
Infrastructure as code (IaC) as the idea that, rather than manually provisioning servers, or setting up hardware through a point-and-click GUI, the "server room" should itself be managed by code. That code can then be put under version control, tested, deployed with automated build tools, and so on. The code also serves as necessarily up-to-date documentation of what the infrastructure is.
The advantages of IaC can be divided into three main categories:
Continuous integration (CI) and continuous delivery (CD) are a pair of practices that, when done properly, greatly aid an organization's ability to deliver software frequently and reliably to its customers. We often hear the combination of these practices referred to as "the CI/CD pipeline," and they are among the most important practices a DevOps team can implement.
Continuous Integration means that every developer should be pushing code to the master branch regularly, at the minimum once per day, and that then that code should be tested to ensure that it integrates with all the other code currently in the master branch. The practice of continuous integration eliminates the huge "integration" phase that typically took place in waterfall model projects. The central repository will receive your changes while automated processes can build, test, and scan the code while providing reports.
Continuous delivery means taking the result of the continuous integration process and delivering it to a "place" in which it can be run. That "place" my be a test server, a staging server, or even production. If the continuous delivery phase is actually putting the new software right into production, then it also qualifies as "continuous deployment." There are many free tools to aid in CI/CD, such as Travis CI and Jenkins.