It doesn't seem that long ago that I had my first job as a software developer. Yet, many things have changed since. I still remember my first software release in the early 2000s. I had worked for months on software for our customer. I had finished all the requirements, and I was ready to ship all this to them. I burned the software and an installer on a CD-ROM; I jumped in my car and went to the customer's office. As you've probably guessed, when I tried to install the software, nothing worked. I had to go back and forth between my workplace and the customer's office many times before I finally managed to get it up and running.

Once the customer was able to test out the software, he quickly found that some parts of the software were barely usable. His environment was different and caused issues that I could not have foreseen. He found a few bugs that slipped through our QA processes, and he needed new features since his requirements had changed between the time he'd listed them and now.

I received the list of new features, enhancements, and bugs and got back to work. A few months later, I jumped into my car with the new CD-ROM to install the latest version on their desktop and, of course, nothing worked as expected again.

Those were the times of Waterfall development. We'll learn what this is about in the next section.

Waterfall model

The Waterfall methodology consists of a series of well-planned phases. Each phase required some thorough planning and that requirements were gathered. Once all these needs were established, shared with the customer, and well documented, the software development team would start working on the project. The engineers then deployed the software according to the specifications from the planning phase. Each of these cycles would vary in length but would typically be measured in months or years. Waterfall software development consists of one main phase, while agile development is all about smaller cycles based on feedback from the previous iteration.

The following diagram demonstrates the Waterfall methodology:

Figure 1.1 – Waterfall versus Agile

This model worked well on some projects. Some teams could do wonders using the Waterfall model, such as the Apollo space missions. They had a set of rigorous requirements, a fixed deadline, and were aiming for zero bugs.

In the early 2000s, though, the situation was quickly changing. More and more enterprises started to bloom on the internet and having a shorter time to market than the competition was becoming even more important. Ultimately, this is what led to the agile manifesto of 2001.

So far, you've learned how software development was done at the turn of the millennium. You've learned how those long cycles caused the releases to be spread apart. It sometimes took months, if not years, for two releases of a piece of software to be released. In the next section, you will see how agile methodologies completely revolutionized the way we build software.

At the same time as I was making all those round trips to my customer, a group of software practitioners met at a conference. These thinkers came out of this event with the foundation of what became the "Agile Alliance." You can find out more about the Agile Alliance and the manifesto they wrote at http://agilemanifesto.org.

The agile manifesto, which lists the main principles behind the methodology by the same name, can be summarized as follows:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Those principles revolutionized software engineering. It was a significant change from the Waterfall model, and it is now the method that's used for most modern software development projects.

Had agile methodologies been used when I originally wrote my first piece of software, there are many things I would have done differently.

First, I would have fostered working much more closely with my customer. Right from my first release, it was apparent that we had a disconnect in the project's vision. Some of the features that he needed were not implemented in a way that made sense for his day-to-day usage. Even though our team provided many documents and charts to him to explain what I was about to implement, it would have probably been easier to discuss how they were planning to use the software. Picking up a phone or firing off an email to ask a question will always provide a better solution than blindly following a requirements document. Nowadays, there is tooling to make it easier to collaborate more closely and get better feedback.

One part of the software that I delivered that made me immensely proud was an advanced templating engine that would let the customer automate a mail-out process. It used a particular syntax, and I provided a guide that was a few pages long (yes, a hard copy!) for the users to be able to use it. They barely ever used it, and I ultimately removed the engine in a future version favoring a hardcoded template. They filled in one or two fields, clicked Submit, and they were done. When the template needed to be changed, I would update the software, and within a few hours, they had a patch for the new template. In this specific case, it didn't matter how well-written my documentation was; the solution did not work for them.

This over-engineered feature is also a great example of where customer collaboration is so important. In this specific situation, had I worked more closely with the customer, I might have better understood their needs. Instead, I focused on the documentation that was prepared in advance and stuck to it.

Finally, there's responding to change over following a plan. Months would go by between my updates. In this day and age, this might seem inconceivable. The planning processes were long, and it was common practice to publish all the requirements beforehand. Not only that, but deploying software was a lot harder than it is nowadays. Every time I needed to push an update, I needed to meet with the system administrators a couple of weeks before the installation. This sysadmin would check the requirements, test everything out, and eventually prepare the desktop to receive the software's dependencies. On the day of installation, I needed to coordinate with the users and system administrators to access those machines. I was then able to install the latest version on their device manually. It required many people's intervention, and no one wanted me to come back in 2 days with a new update, which made it hard to respond to changes.

Those agile principles might seem like the norm nowadays, but the world was different back then. A lot of those cumbersome processes were required due to technological limitations. Sending large files over the internet was tricky, and desktop applications were the norm. It was also the beginning of what came to be known as Web 2.0. With the emergence of new languages such as PHP and ASP, more and more applications were being developed and deployed to the web.

It was generally easier to deploy applications to run on the web; it simply consisted of uploading files to an FTP server. It didn't require physical access to a computer and much fewer interactions with system administrators. The end users didn't need to update their application manually; they would access the application as they always would and notice a change in a feature or an interface. The interactions were limited between the software developers and the system administrators to get a new version of the application up and running.

Yet, the Waterfall mentality was still strong. More and more software development teams were trying to implement agile practices, but the application deployment cycle was still somewhat slow. The main reason for this was that they were scared of breaking a production build with an update.

Here be testing

Software engineers adopted many strategies to mitigate the risk associated with deploying a new version of the application. One such method was unit testing and test-driven development. With unit testing, software developers were able to run many tests on their code base, ensuring that the software was still working. By executing a test run, developers could be reassured that the new features they implemented didn't break a previously developed component.

Having those tests in place made it much easier to build in small iterations and show the changes to a customer, knowing that the software didn't suffer from any regressions. The customer was then able to provide feedback much earlier in the development loop. The development teams could react to those comments before they invested too much time in a feature that would end up not satisfying the users in the end.

It was a great win for the customers, but it also turned out to be a great way to help the system administrators. With software that was tested, there were much fewer chances of introducing regression in the current application. Sysadmins were more confident in the build and more willing to deploy the applications regularly. The processes were starting to become automated via some bash scripting by the administrators to facilitate the processes.

Still, some changes were harder to push. When changes needed to be made to a database or an upgrade was required for a runtime, operators were usually more hesitant to implement those changes. They would need to set up a new environment to test out the new software and ensure that those changes would not cause problems with the servers. That reality changed in 2006 when Amazon first introduced AWS.

Cloud computing was to technology what agile methodologies were to software development processes. The changes that they brought changed the way developers did their jobs. Now, let's dig deeper to see how the cloud impacted software engineering.

The cloud brought drastic changes to the way applications were built and maintained. Until then, most software development shops or online businesses had their own servers and team to maintain said servers. With the advent of AWS, all of this changed. It was now possible to spin up a new environment and use that new environment directly on someone else's infrastructure. This new way of doing things meant less time managing actual hardware and the capability to create reproducible environments easily.

With what was soon known as the cloud, it was easier than ever to deploy a new application. A software developer could now spin up a virtual machine that had the necessary software and runtimes, and then execute a batch of unit tests to ensure that it was running on that specific server. You could also create an environment for the customers to see the application changes at the end of each iteration, which helped them approve those new features or provide feedback on a requested enhancement.

With server environments that were easier to start, faster to scale, and cheaper than actual hardware, more and more people moved to cloud-based software development. This move also facilitated the automation of many processes around software deployment practices. Using a command-line tool, it was now possible to start a new staging environment, spin up a new database, or take down a server that wasn't needed.

More and more companies were having a presence on the web, and the competition to get out new features or implement the same features as your competition became a problem. It was no longer acceptable to deploy every few months. If a competitor released a new feature, your product also needed to implement it as soon as possible due to the risk of losing a market share. If there was a delay in fixing a bug, that also meant a potentially significant revenue loss.

These fast changes were at the heart of a revolution in how teams worked to build and deploy applications. Until now, enterprises had teams of software engineers who oversaw designing new features, fixing bugs, and preparing the next releases. On the other hand, a group of system administrators oversaw that all the infrastructures were running smoothly and that no bugs were introduced in the system. Despite having the same goal of making the applications run better, those two teams ended up contradicting each other due to the nature of their work.

The programmers had pressure to release faster, but they would potentially introduce bugs or required software upgrades on the servers with each release. Sysadmins were under pressure to keep the environment stable and pushed changes to avoid breaking the fragile equilibrium in the systems in place. This dichotomy led to a new philosophy in enterprises: DevOps.

DevOps' idea was to bridge that gap between the two teams so that deploying better software quicker was finally possible. Lots of tools aim to make DevOps easier, and containers are one of those technologies.

Works on my machine!

One problem that has always existed is software engineering became more prevalent with the cloud – the "Works on my machine" syndrome. A programmer would install all the required software to run an application on their development machine, and everything ran smoothly. As soon as this software was shipped on a different device, though, everything stopped working.

This is a widespread problem at larger companies where multiple teams have various environments. A programmer would have Apache 2.4 running PHP 8.0, while someone on the QA team would be running Apache 2.3 with PHP 7.2. Both of those setups have benefits. The software developers tend to use the latest version available to benefit from all the new features that would make their life easier. On the other hand, the QA team would try to use the most common setup – the one where most of the customers would be.

This was also very true a few years ago when browsers differed from one vendor to the next. Software engineers were typically using Chrome or Firefox because they provided the best developer tools. In contrast, the testing team would use Internet Explorer because they still had the largest market share.

When teams had different environments, they would get mixed results when running the applications. Some features wouldn't work, or some bugs were raised that weren't reproducible by the developers. Trying to fix issues related to the environment is much more complicated than fixing problems that lie in the source code. You must compare the environment and understand why a specific piece of software did not behave as expected. Often, a note was added to the ticket mentioning either "Works on my machine" or "Cannot reproduce," and the ticket was closed without being fixed.

This type of scenario is prevalent between QA and software engineers and is present for system administrators and programmers. In the same way, developers typically used the latest versions of software, say a database, but the version running on the servers would be years old, so it would continue to support older applications.

A software engineer could request a newer version to be installed, but that was not a guarantee. Perhaps the more recent version had not been tested on the infrastructure. Maybe installing two different versions on a single machine was merely impossible. Either way, if the system administrators couldn't install the newer database, it meant going back to the drawing board, getting a development environment that ran the version installed on the servers, and getting it to work.

In 2013, a new startup came with a solution to those problems. Container technology was not new. In fact, process isolation, which is at the heart of how containers work, was introduced in 1979 in Unix V7. Yet, it was only close to 35 years later that it was made mainstream.

That startup was Docker. They built a tool that made it much easier for software engineers to ship their applications along with the whole environment.

If you are not familiar with containers, they are basically giant ZIP files that you would package your source code in, as well as the required configurations, the necessary runtimes, and so on. Essentially, programmers now shipped everything needed to run an application. The other benefit of containers is that they run in complete isolation from the underlying operating system.

With containers, it was finally possible to work in a development environment that was identical to the production or testing environments. Containers were the solution to the "Works on my machine" problem. Since all the settings were identical, the bugs had to be related to the source code and not due to a difference in the associated runtimes.

Scripting overload

Containers rapidly became a solution of choice for deploying applications in the cloud. The major cloud computing providers added support for them, making it more and more simple to use container technology.

The advent of containers was also a significant benefit to DevOps communities. Now, developers could pick the software they needed, and system operators didn't have to worry as much about breaking older legacy systems with newer versions.

Containers are intended to have minimal overhead. With a minimal set of resources, many of them can be started – much fewer resources than virtual machines, that is. The good thing about this is that we can break down large applications into smaller pieces called microservices.

Instead of having one extensive application deployed occasionally, software engineers started to break these down into smaller standalone chunks that would communicate with each other. With microservices, it was much easier to deploy applications faster. Smaller modules reduced the risk of breaking the whole application, and the impact of each deployment was smaller, making it possible to deploy more frequently.

Like every solution that seems too good to be true, microservices also came with their own set of problems. It turns out that, even with container technology, when an application has hundreds or even thousands of containers running simultaneously and communicating with each other, it can be challenging to manage. System administrators at large enterprises relied on scripting to manage those containers and ensure that they were up and running at any given time. A good understanding of the system was required, and those operators were doing a job similar to traffic controllers; that is, making sure that all those containers were working as they should and not crashing.

Google was an early adopter of container technology and was running thousands of them. They built a cluster manager called Borg to help them keep all those containers up and running. In 2014, they rewrote this project and released it as an open source project called Kubernetes.

Kubernetes is a container orchestration platform for containers. It ensures that containers are always up and running and takes care of the networking between them. It also helps with deployment as it introduces mechanisms that can redirect traffic during upgrades or distribute traffic between various containers for better release management.

Kubernetes is now the standard solution for container orchestration in large enterprises and is available from most cloud providers.

The cloud today – cloud native

20 years after my first application deployments, things have evolved quite a bit. Often, applications are running in the cloud. Tooling is easier than ever to deploy and manage such applications. We are now in the era of cloud-native software development.

There is no need to access a user's machine to release new software; it is possible to push these changes via the web directly. Even in software that runs locally, such as mobile applications or phone operating systems, upgrades are usually done seamlessly through automated processes.

This means constant application upgrades and security patches without the need for a manual process for the end user. These frequent upgrades keep your customers happier and more engaged with your product. If a user happens to find a bug, it can automatically be fixed quickly.

For enterprises, this means being able to push new features more quickly than the competition. With tooling such as unit testing, new builds are generally more reliable, and the risk of regressions is highly reduced. Even if a new feature would break the application in place, tools such as Kubernetes let your team quickly revert changes to an older state while waiting for a patch to be released.

For the software developers, this means less hassle when pushing a new version. System operators are more confident that the microservices won't interfere with other systems in place. With containers, the friction between the teams is also less frequent, and trust is higher regarding the software's quality.

Not only are the applications deployed to the cloud, but applications can also be tested, packaged, and even built directly with tooling that exists on the web. Tekton is one of those tools you can use in your server's infrastructure to manage your deployments.

The future of the cloud

Just like there was no way for me to predict the cloud 20 years ago, I can't predict what we will see in the future. One thing is certain, though: the cloud will stick around for many more years. The flexibility and ease of use that it brings to software development has helped software developers become more productive. Once all the tooling is in place, programmers can focus on their code and forget about all the hassle of deployment.

Already, we can see the emergence of cloud-based IDEs. It is possible to code directly in a web browser. This code is then pushed to a repository that lives on the web and can be automatically deployed to a cluster via some tools that exist "as a Service."

These cloud-native tools will eventually bring even more uniformity across the environment and help software developers work even more closely to build better software.

So far, you've seen how the last 20 years have shaped the web as we now know it and the importance of deploying quicker and quicker. All of this brings us to our topic at hand: CI/CD.

By using automation, it is possible to build more robust software and release it faster. Thanks to containers and orchestration platforms, it is also easier to build microservices that can be published with minimal impact on a larger system. These automation processes are generally known as CI/CD.

These processes are generally defined as three separate steps that compose a more extensive pipeline. These steps are continuous integration, continuous delivery, and continuous deployment.

The following diagram shows the various stages of CI/CD:

Figure 1.2 – Continuous integration / continuous delivery / continuous deployment

Let's take a look at each in more detail.

Continuous integration

The first step in the pipeline – CI – refers to continuous integration. This first automation process is typically meant for the developers and usually runs as part of the development environment.

In this step, the code is automatically analyzed to catch any issues that might come up before the application is released. Initially, this step mostly referred to running a series of unit tests, but it can now include many other processes. Those processes include (and are not limited to) the following:

• Installing dependencies: To validate all the code and check for potential vulnerabilities, the CI process would need to install all the project's dependencies.
• Auditing for security vulnerabilities: Once all the dependencies have been resolved, it is essential to check that each module from third-party vendors does not have security vulnerabilities. This process can be done automatically with various tools that match the current versions of those modules against a database of known security breaches.
• Code linting: Software developers tend to have their unique signatures. Think spaces versus tabs or single versus double-quotes. It is essential to have coding standards in a complex code base to increase code readability and reduce errors. Code linting will ensure the code that was written matches the defined standards for this application.
• Type checking: Many programming languages, such as JavaScript and PHP, are loosely typed. While the absence of typing can be a powerful feature of the language itself, it can also introduce hard-to-find bugs. To help find those bugs, some tools can be executed against source code to reveal potential flaws.
• Unit testing: To test out the business logic of the code, unit tests can be run on individual functions. The purpose of a unit test is only to validate the outcome of a single, standalone function. Those tests are generally quick and can be run against a large code base in a matter of seconds. Unit testing has been around since the 1960s but was popularized with the agile movement's rise in the early 2000s. Kent Beck, one of the fathers of the agile manifesto, was a prone supporter of writing tests before even writing code. This approach was known as test-driven development or TDD.
• Merging: Once all the code has been validated with the automated tools, the CI process can merge the code into a branch for a potential release to a staging environment.

The end goal of continuous integration is to automate and submit the code that an individual developer contributed to, to a shared repository. Once all the testing and code analysis has been performed, the code is trusted enough to be automatically merged. With automatic merges in place, the number of branches that need to be manually incorporated into the code base is smaller. This ultimately reduces the potential conflicts between various branches affecting the same code.

Continuous delivery

The CD component can be divided into two distinct steps. The first one, continuous delivery, refers to preparing an application to be delivered. It encapsulates all the steps required to prepare for application deployment. Those steps typically run for longer and are not necessarily executed every time there is a code change. Instead, they run automatically when some code is merged into a repository to prepare for the deployment. This could include doing the following:

• Integration testing: Once the business logic of each function has been tested, it's time to test that each component is working with the other as expected. This process, called integration testing, typically tests a real network response to see if the small units of software work as expected with an authentic response. Those tests usually run longer and are only performed for the components involved in the current development cycle.
• E2E testing: End-to-end testing (also known as E2E testing) tests all the user journeys in an application. These tests extend to the UI, all the way to the network responses from a backend. They take much longer to perform, but they can usually help find regression bugs by testing the application as a whole.
• Compile and build: When applications need to be compiled, such as mobile or native desktop applications, this needs to be done. The output would be an executable or package that can then be installed and tested out by a QA team or a customer to provide feedback.
• Package and containerize: With some applications, it makes sense to prepare a container for distribution. Building this container and pushing the resulting image to a registry would be done at this phase.

Ultimately, the result of the continuous delivery phase is to provide the team or the customers with a version that can be tried and tested quickly. Continuous delivery was created in response to slower application delivery, which used to rely on manual processes. With faster delivery comes faster feedback, which is the goal of agile methodologies.

Continuous deployment

Finally, it is possible to automate the whole process even more. Now that the application has been packaged and ready for release in the continuous delivery phase, why not go one step further and automate deploying into production automatically?

Depending on the definitions, continuous deployment will often be part of the continuous delivery stage, but some people prefer to split those two to emphasize the amount of automation that can happen.

The deployment can take multiple forms and can be further automated using blue/green deployment methods, as an example.

CI/CD in the real world

Most software engineering teams will use some automation processes to help with their application delivery, usually referred to as CI/CD. The amount of automation they use can vary greatly. Some enterprises will only automate processes in the development environment. In contrast, others will automate the whole process and deploy to production as soon as a change has been pushed to a repository. The series of steps that are performed as part of that CI/CD process is called the pipeline.

In this book, you will learn how to build some of those pipelines using Tekton to automate your own processes. These examples will provide you with some simple to understand concepts, and will also help you eventually migrate to more practical examples that can be used in your regular responsibilities as a software developer.

In this first chapter, you learned about the importance of deploying applications faster. By building your CI/CD pipelines, you can integrate processes such as code linting or E2E testing as part of your automated processes to ensure that your applications are more robust.

In the next chapter, you will learn what CI/CD means in the context of cloud native and learn about some of the basic concepts that are used in Tekton.