CI Best Practices

[00:00:00]
>> Before I go into this as well, maintenance, the other piece of this I want to consider, which we have a little bit of time to discuss is regarding the implementation of conventions on continuous integration pipelines. And so I'll make sure that later on when the slides are pushed to the repo, this will be included.

[00:00:22]
So the idea here with continuous integration, right, cuz we talked about automation with implementation. So, when it comes to continuous integration, what we talked a lot about here, there are three main points with continuous integration. There is basically the pre-commit hook, where the developer is committing code, there is the pull request step where tests are being run just to make sure that things aren't breaking.

[00:00:48]
And then there is the final continuous integration step where things are being released to production, those are the three main categories to think about when you're thinking of continuous integration. The reason why it's important to distinguish between these three, is because it will determine how much time you should be spending on each one or allowing it to increase.

[00:01:08]
And so, as we sort of mentioned earlier, right? With the Pareto effect and keeping to that 20% to 80% impact rule, most of the time when you're committing code, you need to be able to basically make sure all the basic linting and all the things we're talking about here, that all of these things are consistent, we wanna get rid of that crust.

[00:01:27]
And then once that's done, right? You can theoretically then consider adding some tests to the commit pre-hook, but in my experience, unless you're able to keep your unit tests for whatever changes are being made to basically a minimum. Like basically it should run really quickly so that developers don't feel like they can walk out and go get a cup of coffee and then come back for the test to run, that is the key thing for the success of integrating any convention inside of that pre-commit stage.

[00:01:55]
And so as long as user can commit and call it within 30 seconds, I'd say, like it's a good baseline that everything's done or to be honest, probably even less, then this is good, this is stage one of your implementation process for conventions. When you get to the pull request section, one of the traditional mistakes that's made with continuous integration, is you try to test everything, right?

[00:02:19]
And so what you ultimately get is, a really long review process, and this is extremely costly because what this means is, especially with time zones, you lose development cycles. Imagine if the developer pushes something to their pull request, and then it takes, let's call it, 30 minutes to run the test, but they've already switched contexts at this point.

[00:02:39]
Cuz people aren't just sitting there waiting for their PRs to pass, right? They've moved on. And so they might not discover that the tests have failed until, an hour, an hour and a half later, and then this means that then when they need to fix the thing, they now need to then push and then wait that whole cycle again or and if you have any locally You still have to wait for that to work.

[00:02:59]
Again, at each stage, we are trying to still keep things fast enough that we focus on the important thing which is, one, the review and then two, moving it forward. So the kind of tests that are generally recommended at this sort of pull request stage is to focus on tests that only impact the feature that has been changed.

[00:03:16]
So, if you have changed the shopping cart component, that then the appropriate unit tests, or enchanters for that matter, or in this case, probably unit tests are probably the best ones, are in any dependencies that are on this shopping cart. You wanna make sure those are run, because obviously that's what you need to actually automate and test out.

[00:03:35]
But then if you're trying to test everything else at once, I think that is where the mistake is often made. So scoping your test down to what's relevant to the PR is really important for ensuring that people can trust the PR process and basically move things forward. Now, as you probably might have guessed, when it comes to pushing to production, this is the time where now you're gonna want to go ahead and run it all.

[00:03:59]
And so one way you can try to mitigate this is because a lot of people would say, well, this doesn't necessarily work well for my organization because, sometimes, we need to push something, it needs to go to production, and if we have to wait all this time, this is not good.

[00:04:18]
And so what often a lot of best practice for a lot of organizations they do, is they'll basically have a, call it a either a staging or a dev branch that contains what should eventually go to production, and that's what's basically running the entire suite of end to end tests.

[00:04:32]
But that's being run separately from everyone else's development workflow. So that that way at least by the time they context switch, if someone did break something on the dev branch, for example, then they can go in and fix it accordingly and we can figure it out the trace path for figuring out what went wrong is a lot easier.

[00:04:49]
And so that is one way to sort of mitigate having that entire test suite take up a lot of time for deployment, is to have that run on a separate branch, sort of as a, call it a test run, and make sure everything runs smoothly. Cuz the last thing you want when you're supposed to push a new feature out is to find out there was this one random test that failed because of xyz dependency.

[00:05:09]
And so those are the three main stages to consider when it comes to how implementing conventions go across a continuous integration pipeline. So does anyone have any questions regarding best practices or wanna talk about challenges they've had as far as either trying to bring things up or strategies they could use etc?

[00:05:37]
So I'll open the floor up for questions. The question around best practices, what are my thoughts as far as call it the CTL just going, by the way, we're gonna follow the Airbnb standard for how they read JavaScript or the Google one and that's what we're doing? There's certainly nothing wrong with this, right?

[00:05:54]
The obvious benefits of this is you avoid the bike shedding and you start with a convention that is fairly popular and most people probably won't debate a lot about. But when you're starting a new project, I think with conventions, for longevity of these sort of things, I think it's important to give people the emotional buy in, to understanding why conventions are being chosen.

[00:06:16]
One of I think the biggest problem is we see as the tech culture continues to grow and develop, is a lot of developers often follow principles without understanding why they're doing it, right? A great example of this is, do not repeat yourself, right? All my code needs to be dry, and so if I have things I repeat across components, that's wet code, we enjoy typing.

[00:06:39]
And so then they'll contort themselves to try and figure out how to make their code as dry as humanly possible. When again, this would most likely probably fall into that 80% for probably not even 20% of impact, it's a principle that then the develop waste time trying to figure out this also means that ultimately it's okay that we repeat.

[00:06:58]
But if you don't understand why we're doing these things, and when it's appropriate to do these things, this is where I think we lose context over time. And so don't get me wrong, it's always good to start with a standard, and when you're onboarding developers to the standard, I think it's important for them to at least start to understand the key things about certain standards so that they basically have that connection to what's happening.

[00:07:22]
Because overtime, right? We talked about this conventions will change, and the requirements of each teams will change as well. So, if as an organization our goal is to grow our engineers and to grow as a department, this means we need them to be able to make basically good decisions on behalf of the department.

[00:07:41]
And not simply just take marching orders from the top down which is understandably, it's quick and gets the job done, but I think ultimately, having those discussions, again it's not necessarily that in your example where we're saying, let's tear apart Airbnb standards and pick which one we want.

[00:08:02]
That can be a huge waste of engineering time and even arguably impossible across a large department. But what we can do is that, when you start with a standard, for example, when you use Vue CLI you might've noticed, or you might not have noticed, that inside of our packets are Jason.

[00:08:20]
They're actually our IES lint plugins, like for the essential rules, that we basically like recommend that you follow. And so to this point, it is good to have a starting point because for example, there are certain things that are more or less agreed upon conventions across the industry.

[00:08:36]
And so starting with there's nothing wrong but then going forward as you bring on new people and have those discussions, it's important to us, as long as they're given the opportunity to question those things, right? And then have those discussions in a safe environment, not necessarily with the CTO, for example, but with their team lead, like, I noticed that we don't have this rule for this thing.

[00:08:56]
I know that Airbnb doesn't do this, but why can't this be improved upon? As long as those discussions are allowed to happen, I think that is the key to ensuring that over time, you have the long term benefit of having conventions while also growing your engineers. Okay, so the question here is around if you use JSX there are linting tools to help with accessibility?

[00:09:20]
I don't have any on top of my head immediately for non-JSX within the Vue ecosystem but I would not be surprised if someone has already created that. And if they haven't, definitely would be a very popular one for sure so, yeah, so, unfortunately, I don't know any off the top of my head.

[00:09:39]
But checkout again, I don't have an encyclopedia of knowledge of the entire ecosystem, but I do think that there are a lot of people in the ecosystem that are very passionate about accessibility and who are leading the charge on this. Real Amado is one of like our key accessibility leads in the community ,and so if you check out the Vue three guidelines, there is like an accessibility section in our docs now dedicated to these things.

[00:10:04]
So if you all are having questions around these things or think that this tool would better enhance our experience as Vue developers, I absolutely recommend either opening an issue on the docks or something so we can start having those discussions and figuring out a way to better help everyone across the world.

[00:10:19]
So earlier we had a question regarding an eslint plugin to Vue, that helps to basically lint for accessibility things. So shout out to Patrick for finding this during the break, and so yes, there is a eslint view ally plugin as you can see here, that you'll be able to install and configure.

[00:10:36]
And as you can see here, there's a lot of base supported rules for different accessibility things, and definitely be sure to check it out. Also, this is a GitHub repo as well, I'll go ahead to make sure those are included inside of the repo as far as resources go, as we've been going through, throughout the day.

[00:10:56]
And so yes, big shout out to Patrick for finding that, I know a lot of people will benefit from having this as part of their app.