I'm here with Ricardo Feliciano. Ricardo is from CircleCI. Ricardo, thanks for joining us. >> Thank you, Alex. >> CircleCI is a CI application like Travis or Jenkins that helps teams standardize, and automate, and generally make it easier to run automation on their pipelines. And Ricardo is going to give us a demo of how this works on the CircleCI product to make this process of a little more tangible in case you're not specifically familiar with it. So with that said, Ricardo, I will hand it over to you for our demo. >> Awesome, so I'm going to go ahead and share my screen So today I'm going to show an example of how you can use CircleCI to do a build test and deploy scenario like a pipeline for a web app. In the specific example, what we're going to be using is a clone of the CircleCI documentation website. And this is the project that I'm going to use to demo how you can use CircleCI for a build test and deploy pipeline. So for this demo, we have a sample site that you can see here. And basically, we have the headline, Welcome to CircleCI Documentation Website. Now, this is our website, once again, that's booked with a tool called Jekyll, and Jekyll is a static site generator. And what that uses is HTML and CSS files together with something called Mark Down, in order to build your website. So for this demo, what we're going to do is we're going to change this headline. From 'Welcome to CircleCIDocumentation Website' to 'Welcome to CircleCI Docs Website.' We're just going to shorten the word documentation to docs. So I'm going to hop in to my terminal here. And we have that homepage open now. So this page here, this is the mark down file for that page. >> And what we're seeing here is the page in the repository that you showed us earlier from GitHub. >> Exactly, so we're going to go to our H1 file, H1 tag, sorry, which is the header tag for html and we're going to change the word documentation. We're going to shorten that word down to just docs. I'm going to go ahead and save that and then I'm using git to version my files for this website. I do git add and the path of the that change which is index.html. And then we're going to do git commit and write a commit message for the changes that we're doing. So I'm going to say, change the header to short version. And then we're going to go ahead and push that commit that we just did to GitHub using git push. While that happens, CircleCI is a tool that integrates with your code base, based of your VCS provider, in this case GitHub. So on GitHub, that latest commit that I just pushed is available now. You can see it was published 21 seconds ago and CircleCI is already integrated and going to be pulling those changes. So this is the CircleCI dashboard for my project. On circleci-docs-clone. And we'll see that we have a build running in the right loop. Let's actually pull that change that I pushed out to GitHub, and is now running on CircleCI. We're going to dip into the CircleCI config file, so we can get a better idea of what's happening during this. So in your repo, you're going to have a dot CircleCI directory. And in that, you're going to have a config.yml file. Dot YMO is the extension for Yemo which is a syntax used to configure CircleCI. So in this config file, so basically, what this is doing is this is a set of instructions that tell CircleCI how to run your build and what to do. So the main build starts here. Where we have our jobs on build. And it uses a CircleCI ruby image, which is just the environment that Jekyll needs to run in, since Jekyll is a ruby program. Have a- >> Is that a doctrine image, Ricardo, or what is that exactly? >> Yes, yes, so right here at the top, when we specify CircleCI slash ruby, what we're doing is we're specifying a CircleCI docrine image that contains ruby and other tools that are preferred to run instead of a CI environment. >> Got it. >> In our step section is where we have the individual steps that make up a job and what are you running. This first step here is an important step, what we call is a special test or check up. And what check up does is it basically get clones your projects code from GitHub into the CircleCI back to container. So this step is how CircleCI retrieve your from GitHub. The next step is a run. A run is basically any bash command that you can give to CircleCI to run. In this case, we're going to be running our first series of tests called test marked on files. And basically, what this is doing is this is using a tool called MD proofer and it goes through our mark down files and it links them. And by linking them, it's going through any of the YML codeblock examples that we have to make sure that we're following the syntax of YML correctly. So we don't have tabs where there should be spaces or any invalid characters into those files. So this allows us to automate the testing of all our markdown files before they actually get generated into the website. Another important step is this run step here, which is build the Jekyll site. So for this step, we're actually running the Jekyll command, Jekyll build and we're actually telling Jekyll to use our mark down files, our CSS files. And our HT [INAUDIBLE] Javaster process build out the final website, which we publish online. Once those files are built, we have another test that we run, this time with the tool called HT Mcproofer. What HT Mcproofer does, it takes your generated HT model and CSS in Javaster files And it runs through a series of online tests. One of them is to validate all of your links to make sure that you don't have any broken links from your website. Another one is to validate HTML itself to make sure that you have proper HTML tags that are opened and closed and match the apostrophe. So other steps here that a CircleCI does is for example store artifacts. The idea behind that is artifacts are files or binaries that a build can leave behind that you might want in the future, for logging purposes, for security purposes, or maybe if you have a project that you're compiling. You can save those binaries as an artifact to use those later. Back to our build, we're going to see that the build succeeded. Basically run two jobs, the build job which were already been through and deploy job. And what that means is while we were going over we refresh this, we'll see that the header of our docs website was updated. This shows how I can write code on a terminal, commit it with git. Push it up to GitHub, and CircleCI can automatically retrieve that code. Run my test and then publish it straight to production. Now this is an example of how things work when things go well. What's most important about STI and a CI solution such as CircleCI is catching when you have errors. So we're going to go back, hold on a second, and change the link down here. So right now, just like we change the CircleCI documentation from the header to CircleCI Docs, we're going to want to change 2.0 Documentation to 2.0 Docs. We'll echo back into my terminal. I'm going to reopen that index.html file. And on line 12 is where we're going to find the text for the link. We're going to change documentation and to pin our docks. Now for example, let's say, I wasn't paying attention and my fingers accidentally hit the wrong key or maybe I was distracted by somebody next to me. And the link here which is /dock/2.0/, I accidentally removed that decimal there. So instead of /2.0 it's just /20 now. And we're going to go ahead and commit this. >> And that means we're linking to a page that doesn't really exist. >> Exactly, this is an example of maybe not paying attention when tapping the wrong thing and we now linked to a page that does not exist on CircleCI docs. I'm going to add that file with git message would be, change link text. And just as before, we're going to push that new change up to GitHub. Again, we're going to go back to the CircleCI dashboard. I'm going to go back to the main job page here. And we'll see that another build's already kicked off. So the code's already reached GitHub, and CirclecCI's already pulled that code from GitHub and started a new build. While that build is going, I'm going to go into the second job that we have here in our circleci-config file. And this job is called the play. Now, the difference between this job and the first job is that the first job is where we actually take the code and build on our site. And that job runs on every single commit to our core base. The second job, deploy, where you can use a different docker image called ci-build/base. And in this case, what we're doing is using this to actually deploy the website. Because this is only for deployment, this job will only run when we push the master branch, which is what we're using right now. So the idea is, if you're working on a new feature, if you're working on a new page that maybe is not ready for public, you can do feature branches with Git and GitHub. And this job won't run and that code won't be deployed to production. >> If we just connect the dots for our learners, we've talked about a kind of reference pipeline where you go from unit to integration system test, where would you invoke those types of tests if this was, say, a software application or something like that? >> So in a typical programming project that you would build, so CircleCI is very flexible and you can kind of create the pipeline that suits you best. So typically, most people will have a build or test job up here and most of the test will be in this job. >> Now with CircleCI and what we call workflows, you have the power to paralyze jobs. Meaning, two jobs, or two or more jobs can run at the same time in parallel. So where that really becomes important is when you have a bigger [INAUDIBLE] project, where if you have enough unit test that maybe they take 20, 30 minutes to complete, you can actually have job where you run your unit test, and you can have your separate job where you do things such as code coverage or link in. And have [INAUDIBLE] since one of those types of tests doesn't necessarily rely on the other. >> Got it. >> And then you can also wrap it together again at the end with for example a deploy job that waits for those other parallel jobs to complete. And then once those jobs are complete then finally the deploy job will kick-off. >> Got it, thanks. >> Well just to finish up here, basically, what this job is doing is we're adding our SSH keys into the container. And then we're using arson to sync up the files between what's on the container right now, and our production server. And that's how the files get to our production webstie. Going back to the CircleCI dashboard, we're going to see that our build failed. So if you remember earlier we accidentally deleted a decimal from a link which means that you are non-existent. So when the CircleCI build ram, it says that our build job has failed. So we click the build job and it's going to automatically expand the step that failed, in which case test with HTML proofer. So HTML proofer reports that it ran in 278 HTML files that we had and when it reached the file jekyll site docs index.html which is file that we edited. It says that we are internally linking to forward/doc forward/20 which does not exist. So it returns an error, and in CircleCI world, typically, what that means is you're returning an exit code of one or higher, which toss CircleCI at the build fail. So we have an exit code of one, the build failed, and our code never passes the build job, which means deploy never runs. So in this scenario, on CircleCI has caught an error that we accidentally introduce to into the code and failed the build and prevented it to be deployed. So if we go back to our website here, we're going to see that that link did not update. And the link did not update because we broke it by accident. >> And so what would happen now is, hypothetically, the developer would go back and fix this, run it and then merge in and deploy it. >> Exactly, you can go back and fix it, and then for bigger projects, you can open up a PR and have all the team members go through your PR and review your code as well before it gets merged. >> Ricardo, you spend a lot of time with teams and individuals, helping them think about how to engage with a CRCD system Can you talk a little bit about what you've learned is most important for those types of projects? >> Sure, I would say that there's probably three things you want to look for in your CI solution. One of them is the concept of Offset it and forget it. You want something that's like a SASH product, for example, where you don't have to worry about maintaining servers for security and updates. Another thing you want to look for is something that can help mimic your production environment as accurately as possible. And typically, many companies nowadays are using Docker for that. So having a CI solution of course can be important for you. And lastly, you want to focus on scale and flexibility. And a good example of that is doing an Android app for example can take up a lot of RAM. So having a CI solution where you can customize how much RAM a build uses or how much CPU, of course, a build use is very important. And so for lastly, I think continuous integration is very much about iteration both in the code itself as well as your team. So having a solution where you learn as you go and whatever works best for your team is the most important. >> Well, it's a great demo and some excellent perspective from the thanks again, Ricardo.
