My coaches and mentors gave me a time-sensitive project to emulate a work environment. They decided to assign me with a project using another CI/CD platform (TravisCI) that I have no experience in to simulate my hopeful soon to be new role as a Junior DevOps and/or Cloud Engineer. As a result, I researched medium.com for a guide. I will explain to you the process of continuous integration and continuous delivery and deployment using my previous posts code and Github repositories.
First things first, let’s navigate to TravisCI and sign in using our Github account.
Next, since we are using the Github repo from my previous project, we will enter in the environment variables (very similar to Terraform Cloud). I will provide that terraform config files below for your convenience.
Iam.tf
https://gist.github.com/bdc0d583e479951a87a6c4d4d233a597.git
Variables.tf
https://gist.github.com/bmwitcher/a6251754da4af0bb6ed3e7c816939660
Above we included our login credentials for AWS and the default region where we want to deploy our infrastructure.
Adding Travis YML Config
This was explained by another, more experienced user on medium. “Travis gives us the ability to define your pipeline using YML config so that you never have to worry about dealing with manual interactions again. This gives you the flexibility to define a new pipeline for every repository you own through code as part of your development process (DevOps)
Create a new file in the root of your repository called .travis.yml and populate it with the following (full list of commands can be found here).”
https://gist.github.com/32b97a2226440049039a4ab547b4acc3.git
Now that we have our YML in place let’s push our code to GitHub and then head over to start creating our Pull Request (PR)
This step gave me a few errors when using the CLI to push my content to GitHub. Ensure that your git hub has been cloned locally and that you create a new branch and push it properly to the origin.
Creating a Pull Request
On this step, I cloned my Git repo (git clone [used the https link])
Once your remote repo is cloned locally, then you can add the .travis.yml file. I used vim to add the file to my local repo then push it to the remote branch (travisbranch). If you don’t have the proper branch set up try git checkout -b <name of branch>. Then run:
git add .travis.yml
If you would like to but a message to identify the version message
git commit -m “version 1”
git push origin <name of branch>
Since .travis.yml is a hidden file you won’t see it appear in your Github repo but it is there. If you then navigate to Travis CI it may already be planning and applying your terraform code. Let’s take a brief look at the Travis CI outcome. I have run this code multiple times and similar to the Terraform Cloud on the first application you will get errors due to the sequential creation of IAM resources no worries just run it again and it will tell you that the IAM users already exist but then you will find that the user policies and keys have been created for each user.
Above you see the error, I was explaining. You will see the resources created after no changes and another prompt of “restart build.”
Below is one user that has been created along with their access key, and user policy attached showing a successful creation.
For this lab manually delete the five users prior to exiting the lab unless you need them for future use. If you do, .guess what? Click “restart build” and they will all re-create with new access key ids and the user policy 😁.
In summary…
The beauty of continuous integration and continuous delivery tools. Travis CI is another platform such as terraform cloud that can implement multiple languages and automate the deployment and delivery to your clients or work environments. I will add that Terraform Cloud makes it much simpler to automate the destruction of resources. In this case, I manually deleted the users because it was a small number of resources. I will emphasize that I DO NOT RECOMMEND manually deleting resources however until I figure it out it was the best option 😂
