I own this nice LEGOs a long time ago, that really, I wanted to build for my kids when they were young. Have you ever tried building a LGO project without any instructions or idea all the parts that you're going to need to complete the project? Seemed easy enough when it was just a few 100 parts, but when I got to thousands of parts, let's just say the results weren't stellar. After a couple of weeks of toil with the project and exhausting all my free time, I finally threw in the towel. My first frustration got the best of me, but I finally realized an important lesson from them. Those instructions were key to understanding the requirements of all of the parts and how they would come together to finish the work I had embarked on. In this video, you will learn how to manage various Base Continuous Integration Requirements, and describe how Travis provides a mechanism for us to work with those requirements. Let's begin. As a developer, when we think about our code, we always begin with identifying the problem we're trying to solve. Developers can take several approaches of writing the code to solve an identified problem. They may use test-driven development, also known as TDD, or they may take a pair programming approach to get things started. Those exercises usually start with requirements. For the approach, we must ask ourselves, what does the software need to do to meet the stakeholder's expectations or customer needs? In a sense, we're building the instructions required to manage the software assets we're trying to deliver for our stakeholders. In continuous integration, we have the same challenge. As the developer, what are my requirements? To transform the code into shippable pieces of work. CI requirements can come in many forms. The requirements may help us answer questions about runtime testing, unit test case testing, how we compile our code, how we package the code, and how we publish or ship the final results. This may also include answering questions around system constraints for CPU, memory, and disk space. There may even be additional requirements you might have around signing and encryption. Let's explore some of the features in Travis that can help us turn those requirements into code artifacts for continuous integration. Just as a reminder, the travis.yaml file is a YAML configuration file that needs to be created in the root of the source code repository project that you're building with Travis. YAML stands for yet another markup language, which is organized in a series of key value pairs which will describe the configuration for the continuous integration project with Travis CI as code. We've picked our language. Now, we need to select the right compiler to build our code. The first step in configuring your travis.yaml configuration file for a built project will be to select a language that you will need to build and test your software. There are many languages to choose from, that Travis CI support out of the box. Language selection using the language YAML tag can enable compiler tools needed such as Ruby, Java, NodeJS or Python. Travis CI makes a full list available in the help document. Once you understand the operating systems your application will need to support, you'll want to make sure you select an operating system that will make any compiled binary compatible with the operating system. Selecting an operating system can also help the scripted portions of your code be functionally compatible as well. So, the specific OS features of tools that you use to work with are working as expected. For example, using a POSIX compliant operating system guarantees that certain Unix commands work across various OS versions and flavors. The supported languages will for the most part be made available on default operating systems with Travis, which is Linux-based. For the most part, language selections, this will be a boon to LTS. The operating system will be automatically set up in a Container Runtime Environment. However, for special cases such as building Mac OS components, it's possible to use the OS YAML tag selector in the travis.yaml to select OSX as an operating system and set. Now, it's time to identify all of the tools, libraries, and testing tools we might need to complete all aspects of building and validating our project. This is done through a series of installation commands that can be performed on the operating system you selected. We do this through elevated permissions on the operating system chosen. Once we have access to change installed tools on their operating system, we can use various packaging, compiler packaging, or simple download commands like curl, to install the necessary additional tooling. You can choose to use sudo, YAML tag to elevate the permissions allowed during the project build execution. Setting the value to enabled gives the building account permission to perform additional actions such as install a new library or package, that you might be required to compile the build. The elevated a command might look like sudo, app-get update, ampersand ampersand sudo app-get install minus YPython_yaml, which updates the packages list, and installs the Python library extension for YAML. Now you can use YAML libraries and projects that's required in your codebase. The commands required to perform the build can be listed in an array of YAML specifications using the before _install YAML tag, in the travis.yaml configuration file. Each installation element for the tools that will be required for testing would be listed line by line beginning with a dash to designate the beginning of an array element in the YAML specification. If you're unfamiliar with how to use yet another markup language, or YAML, it's good to read up on some of the common syntax from the specification. I've included some additional resources in this module that will help you out. Even with the options to select compilers, operating systems, and testing tools, it might be simpler to leverage a ready-made testing environment that has been published as a container image. Docker containers offer a type of virtualization, where you can define tools, compilers, and files as code in a docker file. This is a text-based configuration file that is used to pass to a docker build command, to generate a common container image format. One of the best advantages of using containers is that we can build and package all of the special and unique requirements we might have for our project. If done well, those packaged results can be reusable. Containers offer this advantage. In addition, we can push or publish our container images to a central registry, to be shared amongst that community such as containers found on Docker Hubs website, hub.docker.com. You can enable using and reusing containers inside Travis through the configuration of the services tag in your travis.yaml file. Adding a docker array element to the tag signals to Travis CI that the docker command is required and makes available the ability to execute docker based commands during the build. At this point, you can start using an executing Docker build commands using the containers you select to build your project. To learn more about how to get started with using docker, you can visit their website at docker.com. System's constraints such as how much memory or CPU resources are available are well-documented for Travis CI is build execution nodes. Travis documents, most of a system constraints under the documentation located on their website. I've included a link in this documentation as a resource for this module. It's important to understand those constraints to help structure how your build will be designed and built. For the most part, these constraints will never be an issue. However, in corner cases, knowing about the constraints can help you make better decisions about the organization and the layout for the Travis CI build steps configuration. For example, you may break up stages or steps in your build into smaller units of work to accomplish this for this space requirements needed to meet the build execution from end to end. Finally, we need to think about being ready to meet the deployment or publishing requirements for your software asset. Once your build is complete, it's important to think about how you package the results. So, they are shippable with the continuous delivery system or step. For example, Travis CI offers simple shipping capabilities with well-known application hosting providers, such as Heroku and GitHub. Using the deploy tag into travis.yaml file allows for customization of deployment steps beyond the build. These deployments steps are especially useful for packaging artifacts that might need to be published. For example, it's possible to use the deploy tag to publish a new package version of your Ruby library to RubyGems registry provider. Travis CI supports a large number of deployment providers that can help create the hand-off needed to continuous deployment environments. Again, you can read more about these providers within the documentation found on the Travis website. In this video, we've really only scratched the surface on the types of basic requirements we should think about when creating the flow for our continuous integration environment. We reviewed key aspects of capturing our build requirements as code. This is important. It leads towards getting reproducible builds for our built environment. Regardless of whether you are using Travis or not, we now know the languages we'll need, how much resources we're going to require, any special packaging capabilities we might need, one additional tools we need, and how we'll ship our code. Having an understanding of our end-to-end continuous integration requirements for our projects helps us build the automation and the instructions to produce a more complete solution for our continuous integration needs.
