Building CI/CD Systems Using Tekton

Joel Lord

• Editorial: Packt Publishing
• Año: 2021
• ISBN:
  9781801075862
• Edición: 1
• Categoría: Computer Science
• Categoría: Systems Architecture

Automate the delivery of applications using Tekton Pipelines and Triggers to deploy new releases quickly and more efficientlyKey Features• Learn how to create powerful pipelines using CI/CD tools• Understand how to run, deploy and test applications directly in a cloud-native environment• Explore the new Tekton Pipelines 2021 featuresBook DescriptionTekton is a powerful yet flexible Kubernetes-native open source framework for creating continuous integration and continuous delivery (CI/CD) systems. It enables you to build, test, and deploy across multiple cloud providers or on-premise systems.Building CI/CD Systems Using Tekton covers everything you need to know to start building your pipeline and automating application delivery in a cloud-native environment. Using a hands-on approach, you will learn about the basic building blocks, such as tasks, pipelines, and workspaces, which you can use to compose your CI/CD pipelines. As you progress, you will understand how to use these Tekton objects in conjunction with Tekton Triggers to automate the delivery of your application in a Kubernetes cluster.By the end of this book, you will have learned how to compose Tekton Pipelines and use them with Tekton Triggers to build powerful CI/CD systems.What you will learn• Understand the basic principles behind CI/CD• Explore what tasks are and how they can be made reusable and flexible• Focus on how to use Tekton objects to compose a robust pipeline• Share data across a pipeline using volumes and workspaces• Discover more advanced topics such as WhenExpressions and Secrets to build complex pipelines• Understand what Tekton Triggers are and how they can be used to automate CI/CD pipelines• Build a full CI/CD pipeline that automatically deploys an application to a Kubernetes cluster when an update is done to a code repositoryWho this book is forThis continuous integration and continuous delivery book is for anyone who wants to learn about one of the most powerful Kubernetes-native CI/CD systems - Tekton. Software developers who want to leverage the Custom Resource Definitions (CRDs) in Kubernetes and use Tekton to run pipeline tasks in order to build and own application delivery pipelines will also find this book particularly helpful. Beginner-level knowledge of software development concepts and Kubernetes is required to get the most out of this book.

Section 1: Introduction to CI/CD

This section serves as an introduction to continuous integration and continuous delivery (CI/CD), why they exist, and what they mean in the context of cloud-native development. You will start by learning about the history of the agile methodology and how it led to the creation of CI/CD principles.

Then, you will learn where Tekton fits into the CI/CD landscape. The main components that are used to create Tekton pipelines will be introduced to you.

By the end of this section, you will have an understanding of why you should be using CI/CD systems to automate your application delivery and where Tekton comes in to help you with CI/CD.

The following chapters will be covered in this section:

• Chapter 1, A Brief History of CI/CD
• Chapter 2, A Cloud-Native Approach to CI/CD

Chapter 1: A Brief History of CI/CD

Application development has not always worked the way it does today. Not so long ago, the processes were much different, as was the available technology for software engineering. To understand the importance of continuous integration/continuous deployment (CI/CD), it is essential to take a step back and see how it all started. In this chapter, you will learn how CI/CD came to where it is right now and where it might go in the future. You will take a small trip back in time – about 20 years ago – to see how application deployment was done back then, when I was still a junior developer. We will then look at various turning points in the history of software development practices and how this impacted the way we deploy applications today.

You will also learn about how cloud computing changed the way that we deliver software compared to how it was done about two decades ago. This will set the foundations for learning how to build powerful CI/CD pipelines with Tekton.

Finally, you will start to understand how CI/CD can fit into your day-to-day life as a software developer. Pipelines can be used at various stages of the application life cycle, and you will see some examples of their usage.

In this chapter, we are going to cover the following main topics:

• The early days
• Understanding the impacts of Agile development practices
• Deploying in the era of the cloud
• Demystifying CI versus CD versus CD

The early days

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.

Understanding the impacts of Agile development practices

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 ...