CI/CD Success for Vue Developers

All right. Hello. Thanks for having me over. So today we'll be talking about CI and CD success with vue.js in particular. But first, let's start with a thought exercise. Think about a time when you were getting ready to release some software. Maybe it's something you'd worked on for the past week, maybe it's the past four weeks, maybe it's the past six months. Hopefully not much longer than that. Anyway, everything has been tested, everything is ready. It's just waiting for you to press this big red button, which then initiates the deployment process and will get the software in the hands of your user. So without further ado, you press that big red button. It has a nice audible click. It's very satisfying, nice, satisfying tactile feedback as well, like only a nice mechanical keyboard can have. And then it's off to the races. The software is out of your hands and things are being deployed. And in a matter of minutes, maybe hours, depending on what you're actually deploying and how it's actually done, this software will be actually used by your users. And all you can do is hold your breath and sit in silence. And then you have two options. Option one, you keep holding your breath, sweating, and nervously waiting for it to actually start blowing up. Some errors showing up and your users complaining. Or option B, pack up, go home, because it's 4pm on a Friday and you've done your job. I certainly prefer option B, partly because it is 4pm on a Friday when I'm recording this, but also because it's just a nicer thing to do if you want to enjoy your weekend. Anyway, the difference between the two though, it's really just always down to automation. And it's always down to automation. From software to processes, manufacturing, and yes, also agriculture. While we're not talking about agriculture today, I do like to compare software delivery lifecycle with the process of growing and tending for crops. So if you imagine you have a field like this, you can have hundreds of people working that field, planting everything, picking everything manually, watering, weeding, all those things done manually by hundreds of people. It gets the job done, but it's not as reproducible as one might want. Of course, you can do it with a lot fewer people if you employ some tractors, if you get some irrigation systems in place, or take this a few dozen steps further and put everything in a greenhouse with controlled atmosphere, controlled lighting, controlled nutrients that are directly fed to each individual plant. And I like to imagine that these robot hands, they use computer vision to pick the plants at their best ripeness for essentially selling them at optimal profit. And that's what I like to compare to a really finely tuned CI-CD system. Everything is automated, everything is out of your hands, and things just work. Until, of course, they don't. And while I'm not expecting your CI-CD system and the robots in a greenhouse to suddenly rise up and turn into dinosaurs that try to kill us all, they can definitely A. kill your crops and B. your CI-CD system can definitely ruin your day if you've deployed something that's not really deployable. But yeah, fret not. It's never the machine's fault. It's always us, you know. It's always the humans that kind of program these machines, and it's our fault to actually break things. And with that thought in mind, my name is Enmarken. I'm a developer advocate at CircleCI, and I do break a lot of things. And I'm often the problem between keyboard and chair. This talk is titled CI-CD Success with vue.js and for vue.js developers. But the tips and tricks I'm handing out here are essentially universal for every CI-CD system, for every programming language, whatever you're building, however you're doing it, most of the things will always hold true. As I mentioned, I work for CircleCI. We've been around for 10 years. We're the world's leading CI-CD provider, and a huge number of teams all over the world working on so many different platforms, programming languages, with programming paradigms are using us, including parts of vue.js as well, the open source projects, which is really cool to be now talking to you about this. So yeah, this is not a talk about CircleCI. This is a talk about generally CI-CD best practices, optimization, tips and tricks to help you get the most out of it. But as we're talking about CI-CD, what does it actually stand for? What does it really mean? So it's a double acronym where CI stands for continuous integration. And this is the practice of getting all the changes automatically built and tested as they are pushed to remote repositories by developers. So if you're working on GitHub, on a GitHub project with a team, every time you push a commit, the CI process will essentially run all your tests, do all verifications that you might have, like security scanning, static code analysis, and ultimately produce a built application. In addition to that happening automatically, everything is also happening in isolation. So that's where the greenhouse analogy comes from, because all the builds, all the tests, they are run in virtual machines or Docker containers, which are spun up from scratch, essentially. So you just specify the type of environment you want and then all the necessary steps. Everything is also configured with a configuration file which lives inside of the same repository. At CircleCI, we use YAML, but you could use any other format for that. But ultimately, yeah, you codify, everything is tied to the same commit, and everything is reproducible. That's the CI part of it. But now that we have our app built and tested and ready for prime time with users, we also want to deploy it. And CD is the part of it that actually does the deployment. And yeah, again, it doesn't matter what environment you're deploying to. It could be a preview environment for your vue app, or it could be a production kubernetes cluster that you're trying to get this software to, or anything in between, really. But yeah, the continuous deployment step is that. And as you might imagine, this whole ci cd thing has very many dimensions that we need to essentially be on top of. We need to think of, we need to take care of in order to be successful. And yeah, we need to be successful in every single one of them, because every single one of them can actually hold you back and prevent you from having a good time developing something. So yeah, in this talk, we will be untangling some of those dimensions and breaking them down and talking about tips and tricks for it. First one, probably most obvious dimension that we can think of is speed. How fast does your ci cd pipeline run? That's like the most obvious thing you can think of, especially if developers are counting on your CI to actually tell them whether their work is essentially passing all the tests, is successful. As soon as you can get that information to them, the better, because they can continue their work. But there's more to speed, much, much more to speed. The other one could be time to recovery from a failing build. If you're thinking that if you're working off of a main branch and you merge something that doesn't pass the build, so the build essentially goes red as opposed from green, you want to get that back to green, back to passing as soon as possible, because your main branch is essentially where you can get all the deployments out to your users, to your testers, to your stakeholders. So yeah, that's another very important facet of speed. And then there's organizational speed considerations like time to ship a feature. How long does the organization, does my team need from getting a mandate to a product manager for a new feature to actually shipping that to users? CI can definitely help you build that continuously. And obviously CD can definitely help you get that to users as soon as possible, as soon as it's ready. And yeah, all the updates as well. And lastly, there's things like you might not think about as speed, but it could help you onboard new team members, because as I said, everything is configured in code. Everyone can read YAML, hopefully. So a new team member can then be just pointed to this ci cd configuration and tell, hey, these are the environments, everything, all the jobs that we're doing, all the different types of tests. Maybe you're doing unit tests. Maybe you're doing integration tests. Maybe you're initiating some smoke tests as well. Maybe you're doing like a canary deployment, like a really advanced type of deployment. And a new team member can actually understand what's happening and then ask you questions about individual portions of that essentially pipeline, which is all automated, which is beautiful. Anyway, speed, running things faster. First thing to do is really think about whether you're running things on the right size of the machines. So you've got a developer laptop, and that's probably got a number of gigabytes of RAM, a number of virtual processors or threads that you can work with. And if your laptop is building something in a minute and your CI takes five minutes, maybe your CI needs more resources to get kind of more up to speed, literally, to how quickly this might need to work. The second one is things like cache. For example, cache is just reusing things you've already done. For example, node modules, you've run npm install once. Maybe if your package JSON hasn't really changed, maybe that's enough for now. You don't need to update all the dependency. Maybe you can just store them and pull them from cache next time so you don't have to take that kind of loading hit each individual moment. Maybe you're doing some kind of advanced, using some advanced caching techniques, testing techniques with some testing utilities. And for that, maybe you don't want to install everything on your Docker container. Maybe you can just use a Docker image which has all of that pre-installed. So these are all the things that you can cache and really kind of help you speed up the whole thing across many, many runs. Speaking of runs, jobs themselves, so building, testing, various types of testing, can also run in parallel. And also they can be split, especially if you've got a long-running integration test suite or a lot of functional tests, kind of hit different parts of your application as a user would. You can actually split those within a single test suite across multiple parallel test jobs, which essentially run just a portion of that, which obviously takes the time down quite significantly. And of course, you can pick what runs whenever you want to run it. For example, maybe yes, you want to run your unit test. Maybe you want to run some functional tests, but you don't need to run all of them. You just need to do that minimum part and then do that kind of preview deployment of your website, which is good enough for most use cases. But then when you're kind of ready to merge this to the main branch, get ready for a release, you want to run all the tests. So that's kind of speed in general. But what about when things don't go as planned? Sometimes you just break things. For that, you really want to recover things a lot, recover from failures a lot faster. First one is understanding what's happening to your builds, like logging everything, being able to get those logs out. This depends on your frameworks, on your tools, but really invest time into understanding them, understanding how to read the logs, how to get that out. And yeah, just get as much out of your CICD because there's information in there. And my favorite thing is actually being able to debug your builds as they fail. So sometimes your environment will fail, something in your environment will fail. And with CircleCI, for example, we have this cool feature called SSH debug. So essentially SSH into that environment and you can see what's going on as your tests have failed. Maybe there's something wrong with the state. Maybe there's something wrong with the database that you're connecting to. And it really helps you quickly debug things. But yeah, speed is fine. We're all trying to go as fast as possible. But you know what? It's not a race. It's very important, but yeah, it's not a race. And speed is... CICD speed-wise should be seen more like an ambulance instead. So it should definitely go fast, but still keep that payload, keep that signal alive. So signal meaning the quality of your app that's telling you, hey, all of my tests have passed, or some of them have failed. And yes, obviously when red lights are flashing, when the build is red on your main branch, go fix it as soon as possible. Don't let it wait around for that. Anyway, that's speed. Now let's think about some other things like security. Something that can really slow you down as you're building things as many of you are probably very aware that a security review can definitely kind of slow you down. But there's ways to actually get on top of security with a CICD system as well. First one, most important one is actually keeping the credentials inside of the CICD system and using it to kind of really fine-grain your access control policies and really only allowing whoever has the right permissions to ship to or deploy to a particular environment or just keeping the credentials out of your Git repos at the very least. That's something you can do. And the next one is automating security scanning. You know how vulnerable, how easy it is to kind of get some vulnerable or even compromised library into your application. And there's tools available that will just kind of tie into your CICD flow and automate all of that for you so that you're not leaking your customers' credit card numbers or passport numbers or whatnot from the front end, which is just horrid. So yeah, these are the things that you can think about when you're thinking about security. But yeah, there's more and more to the ecosystem than just the CICD system. And there's features beyond the CICD tool. First, obviously, there's the features that are built in. So is there something available that you're not using? It's worthwhile just kind of reading the release logs, release notes every couple of months and seeing, hey, maybe they've released something cool and we can actually utilize this. And yeah, think about whether there's any external services that you're using, maybe product management tools that you're using that you could be integrating with and just tying that into your CICD flow and really informing everyone of your process. And of course, it's never a devops talk if we're not talking about a team. And yes, I mentioned that your configuration is definitely a good onboarding aid. But also it's worth reiterating that CICD is never a single person's responsibility. It's always a team responsibility and just kind of get everyone on board to at least understand what's happening. If not, be able to introduce and suggest improvements to the whole process, because that's going to benefit you all. And obviously, we've initiated deployment in the beginning. And sometimes everything goes fine, but sometimes it doesn't. Things will happen that you're going to break some software, going to break some deploys, and you will need to kind of get stuff back to a working shape. Luckily, we have a time machine because everything is tied to a commit. We can just revert to a previous commit and restart that process. And your CICD process can definitely help you recover a lot faster than you would have to, that you could ever think about doing it manually. And yeah, another thing is because we're doing all those testing, all this testing, all this verifications all the time, we can actually ship a lot smaller changes a lot more frequently and have releases which are a lot less error prone because there's just less stuff to do. And yeah, best thing for this is, best thing to prepare is to plan and to actually prepare and practice to understand, hey, we've broken something. How do we get it back? Let's do a dry run. Let's deploy it back to the staging environment, see how this will fare, how the team is ready. Ultimately, though, to me, to be successful with a CICD system, it means to be free. And it means to be free that you're able to deliver software on the terms that you really control. And that's the best thing you can get out of it. And you can focus on quality, you can focus on team happiness, and you can always adapt faster to change because you're able to ship constantly and release things a lot faster than you would have without the whole kind of greenhouse approach. And yeah, as a benefit, you have the self-documenting build test and deploy process, which anyone can just kind of read and utilize and obviously recover from failure a lot faster because A, everyone understands the whole process and B, it's all reproducible. My name is Andrej Markin. This was a talk on succeeding with CICD for vue.js. I hope you've enjoyed it.