Understanding the basics of CI/CD
Before jumping into the core concepts of CI and CD, it is helpful to understand more about the history and evolution of the software development life cycle. While this section will not present a comprehensive list of all software development methods that may have led to the progress and adoption of CI and CD practices, it will present relevant concepts that will help illustrate why CI and CD are widely adopted today.
A brief trip through the history of software development
Many believe that software engineering dates back to the 1960s. During that time, software engineering and computing in general were costly, which likely nudged software engineers into practicing software development in a similar way to how hardware production was done. In other words, software development started as a slow, cautious, and methodical practice that followed a sequence of steps aimed at delivering perfect products. This method is known currently as the Waterfall model, which is composed of seven phases, each of which depends on the successful and sequential completion of the previous phase. The Waterfall model is known for its inflexible, process-oriented, and sequential nature.
Over time, many issues surfaced in the Waterfall model. For example, extensive and time-consuming planning and approvals were needed before software engineers even had the chance to start writing code. By the time software was written, tested, and deployed, months had passed and customers' needs had changed completely. The Waterfall model did not allow for many iterations, and when changes were needed, this was a long and expensive process that often created bottlenecks and resulted in obsolete or unused features.
While the Waterfall model was predominant between the 1960s and 1980s, there was an awareness that a fast, flexible, lightweight, product-focused, and people-focused—as opposed to process-focused—approach was needed.
In the early 1990s, Extreme Programming (XP) reinforced the concept that tests should be written to describe how code should work, which was also the center of test-driven development (TDD) practices. The XP community then announced a practice that later would help shape what is today known as CI. They announced the use of automated processes to frequently integrate all code across developing teams, with the intention of delivering code that could be sent to production at any given time. This practice has resulted in many builds per day, which improves the predictability and efficiency of the software development life cycle and allows for constant interaction with customers to satisfy their ever-changing needs. This process, in conjunction with other philosophies and software development methods that were gaining traction in the 1990s, later formed the Agile Manifesto.
Many similar software development practices emerged between the 1990s and early 2000s. A group of 17 independent thinkers representing XP, Scrum, Adaptive Software Development (ASD), and other communities met to find their commonalities in approaches, as well as to try to find a different approach to heavyweight software development practices.
The Agile Manifesto was created at the end of that meeting when, among all the different software development practices, the Agile Alliance was formed.
Agile encompasses many practices that are lightweight, code- and people-oriented, and highly adaptive. Other modern approaches, some of which predate Agile, are also based on the idea that the software development cycle should be highly adaptive and built frequently. Based on these premises, CI and CD have gained more space among software developers across the globe.
The main idea behind CI is that automated processes should be in place to test and build software many times a day. This is important because bugs are commonly introduced at the intersection or integration of two different pieces of code. In other words, CI practices manage processes, which allows software engineers to focus on the code itself.
CD follows in the footsteps of CI. It focuses on gathering all changes to code—such as new features, bug fixes, and configuration changes—and sending them to users—or production—as safely, sustainably, and quickly as possible.
CI in conjunction with CD can be both powerful and challenging, given the shift in culture that must accompany the adoption of these practices. When combined and adopted across a company, they can help ensure high-quality, lightweight, and adaptive software development.
Many tools have been created to help software and operations engineers build a CI/CD pipeline. GitHub Actions is arguably the most popular one: it makes it easier to automate the building, testing, and deployment of code on any platform—including Linux, macOS, and Windows—without leaving the repository where the code lives. All of this can happen while GitHub manages the execution and provides rich feedback and security for every step in your workflow.
Because GitHub Actions happen within a repository hosted on GitHub, a GitHub account is needed. Basic knowledge of GitHub as a platform is also helpful. In the next section, you will learn how to create a GitHub account, as well as how to use some basic Git and GitHub features.