GitLab Digital Experience, 28 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-10-28 Buyer Experience deployments with Miracle, Nathan, and Tyler

Description

Miracle, Nathan, and Tyler discuss the existing pipeline for Buyer Experience repository deployments as a video documentation before the end of Tyler's tenure at GitLab.

A

Cool, so we are talking today about um buyer experience deployments. um The reason being is uh like um I did a bunch of work on this like last year um and.

B

A

And it's documented and other people worked on it as well, but this was a lot of stuff where, like I did it once uh and now it is like it just works, which I think is great I'm, proud of, um but also I am uh leaving gitlab, and so this video will just be some good documentation and we can- and we talked about like we're going to go through kind of like we're. Gonna look at a recent deployment.

A

Oh hey, look at that looks like Nathan did something um over here, so maybe we can walk through Nathan's recent merge and sort of talk about like where everything's going and how it's wired up um and then answer questions there. So um because I don't think this is. This is unlikely to change in a lot of ways. I think this. The nice thing is this works pretty well.

A

Scale is pretty good um and like I I also haven't tinkered with this a long time, because I think we just kind of like got it kind of right, which is great, so um cool. So, uh let's look at this pipeline, um so the nice thing is so actually, let's do a couple things here. So um at a top level, all of this is controlled by, like all the source of Truth here is in this buyer experience repository the stuff that we're going to look at is all defined in this yaml file.

A

Right like like, if you want to investigate, what's going on, like nothing happens in the pipeline without this for the most part and like this is where you would go to change things as well, so this- and this is just conventional gitlab CI- that's all documented in gitlab documentation.

A

Unfortunately, we work here at gitlab, so I think you know if you're experiencing challenges with it, you have a lot of access to the right people ask questions, so I think that's a huge virtue for for this project, so um we'll have to like read through the yaml necessarily uh we might do a little bit, but so there's this pipeline.

A

This pipeline uh is running on Main um and it looks like it's Nathan merging uh an MR to clarify OSS language into me, um and so you know every time, basically anytime, something gets merged into main, like this merge request um right, it will kick off this pipeline um and there's a bunch of different stages. So there's the install stage uh which installs our dependencies and it's they're just named.

A

Basically what you see in there. So here's the install stage right- and um it's like, uh like uh it happens beforehand, there's a few rules of like this will happen if it is a merge request, uh it'll only work in this project so like these things, don't get kicked off for forks and that's for security reasons, because, like environment variables, end up in the pipeline, and so you want to make sure that you don't allow this pipeline to get run on a Forks project and have people grab all your environment variables, uh we'll get.

A

There's a couple of sensitive ones that we'll talk about that exist here um and then also like this uh it'll also run. If the branch of a commit is the default branch which for us is Main, and then um you know, this runs like it gets a container and you'll see, we have like default setup for like we, we get this container. uh There's the node Alpine thing uh the node Alpine image right um and it gets this uh sorry I'm scrolling around a bunch.

A

It gets a container and it just runs scripts as though you were running it in a terminal, and that's a lot of what's happening in these stages is basically, we say, like okay provision, a container run.

A

These set of commands move on to the next stage or more accurately, some stages declare that they have dependencies on previous stages right so generally, if you have like this install stage, doesn't necessarily stay say, like isn't defined in such a way that says: okay after you install, then you prepare, it's kind of inverted, so prepare says, do not prepare until install is done right, and so that's how you can get like sequential jobs. If you don't say that these things will often run in parallel, which is also useful.

A

If you want to run things in parallel, so that's and that's defined. This is all this is a lab documentation, but that's defined in like um these needs right. So linting needs installed to have happened right um so I'll stop there does that kind of make sense like as an overview of like sequencing and like where stuff is defined and how it's defined.

A

Any questions cool um so then, so we have this like um prefix, and some of this has actually changed because I don't remember all these stages necessarily but there's a prepare stage. So we actually cache some of these dependencies to make the deployments faster um right, especially like if, if nothing's changed in, basically your yarn lock file like there's no reason to like we can just cache a node modules, folder and say like yeah.

A

These are the node modules that work right so long as that lock file hasn't changed and the rules for the caching here happen in um this node push catch thing which is in the prepare stage and basically um it'll only cache. This job it'll only push the cash from this job to save time elsewhere, um and this I grabbed from um like a boilerplate actually in gitlab. So there's like more documentation around it.

A

um So that speeds things up. um There's some linting. We do uh so I I'm imagining we run eslint and then prettier on stuff, um and so that's all happening here and there's these nice like yaml's nice, because you can comment it and sort of like be descriptive about where things are um I. Would guess there's some of these things? You could probably clean up.

A

I wouldn't mess with it, but you could probably make these rules like shared Declarations of the yaml, um just to be a little bit more like dry it up, but it's it's honestly. As far as CI files go, it's pretty short, it's under 300 lines. It's 252 lines, counting comments, so that's really not not too bad um uh what else. uh So we lit some stuff and then we build it, and so this runs. This is important. This is the thing that trips people up a lot so like this build command.

A

I'll show you in the yaml file. um You can just see what it does. So the build stage is in the so the build um job in the build stage.

A

um Maybe that's poorly named uh we'll run after it requires install, and this is what it runs run to yarn generate so assuming that you've pulled in next dependencies. It runs the command. Oh here's I mentioned this at the beginning, one of the cool things is for the most part because of the nature of our site. You can run this pipeline yourself like go.

A

Look at the script commands and just run them locally, and that's a really good way to debug, and there are ways you can set up um like a local gitlab CI instance for our repository, that's overkill for the most part, so long as you've got node installed and like a couple of these shared programs like curl and stuff like you, should be able to run any of these scripts locally and just basically like, like locally debug. What we've written in this script Block, it's a really powerful thing to be able to do.

A

The same cannot be said of every project with a GitHub CI file. Sometimes you need the CI environment, so you can run yarn generate locally and that's what's happened. That's all that's happening here! That's the exact same thing. This is different than most people's development cycle for expediency. People often run yarn Dev in next, which starts an actual node process that serves as a server and like serves up the next files slightly differently than the static generation does.

A

So when things are going wrong in your build step, you should not necessarily be troubleshooting against a Dev server. You should be running yarn generate locally to see if you can reproduce the errors right. That's that's a really important thing here. So once that happens, um this is really important and Nathan and I have like recently gone over this for a separate job.

A

When you declare this block called artifacts, here's what's really cool is the artifacts from each one of these jobs moves along the rest of the pipeline and and just like, just as like static files, they just get like basically copy paste it over is how you can think of it, and you explicitly say like the path that is. The artifacts of this is just the dist folder. So if you run yarn generate locally you'll get this non-version controlled folder. This is also important.

A

It's not in git, um so like these jobs will always get the full git repository. They will not get the get ignored files. Does this folders get ignored for good reason? That's conventional! So what you say is you say: okay, I have some artifacts from this job. The artifacts are everything in the dist folder they expire in seven days. So after a week we discard them um that goes to any stage that depends on this job right or this stage will get those artifacts in the same place.

A

They'll get a dist folder right, so you can just write a new job. If you wanted to say, like um you know and Nathan I imagine you probably did this for your your 404 thing right. You write a job that depends on the build step and your job says. Okay, now, I have a disk folder. Let me scrape through it to like, find any broken links or like look for a particular phrase to swap it or something.

A

um So that's that's really important for the artifacts and that's how that moves along. uh So it's up there does that make sense. Any questions.

C

Yeah, actually can we go back for one second, um just to kind of, because if you scroll down yeah for the broken link, one I think you'll see that it has dependencies and it needs to install and build. And so it's taking, like you mentioned, like the node modules folder or the disk folder from those two jobs. So if you scroll up actually to the job above, it looks like it's running yarn install again, so in this case, under the test. If you look at the.

A

Test, oh yeah test does not need yarn, install you.

C

A

Yarn test Okay.

C

A

Yeah, so you could speed this up by just removing this line and so long as you make it need install which actually I don't think it does like I. Think that's the change here and actually I think I've seen this so well. Here's the thing, though, is you, may not actually get speed so because this doesn't need anything. This actually runs in parallel um and I. Think I've seen this but I've likes I've like noticed this and be like yeah. That's basically fine, but like interestingly, um this basically just runs totally independent of anything else.

A

um So this Ted, like you know, while all this stuff is happening, one two three four five tests should also be going on its own I might not change that. That's okay to be, apparently, because it's so because it's totally isolated and there's no side effects. It doesn't need anything before and it doesn't impact anything else. It will fail the pipeline if your tests fail, that's good, so you might consider like. Can it should it fail the whole thing and stop all the other?

A

You could maybe save some run time, but like we're git lab so like we don't pay like I, don't know like it's starting like whatever you know: you're, not gonna, save money. Necessarily you save the company money but like anyways, um you know like how much like it's up to like you might do a little benchmarking see if you pick up some some improvements. But if you made this test job need install, you might actually like not see any benefits. You may even it yeah, it's hard to say.

A

um I honestly, you'd have to look to see what's actually faster right.

C

Job dependency, does it show you kind of the job dependencies.

A

Oh yeah I think it does. um Oh.

C

A

So yeah check this out so where's.

C

This yeah totally.

A

C

Oh interesting right.

A

So um yeah, so it's a good call out, though, that like that is a choice you could make, and there might be some reason that you do that or or again it's just something. It's like that's a good demonstration of like how you might use needs to, like sequence out the jobs, because a lot of times the logic of the jobs requires a sequencing right.

A

um I I would probably guess that scan for a broken link since build depends on install Nathan. I would say, like you might, even I, don't think it really matters, but you might be able to clarify the the the articulation of this by only making. This need build.

C

Yeah because builds dependent on install so.

A

Right right, yeah, so you know, but I I, don't think it matters to you. I, don't know if there's any cost for that, it's just something to think about, um and then this dependencies block I think is they might be analogous and there might be. It might be the case that one is deprecated and one's not I. I, don't know for sure. This is one of those things that like go to the gitlab CI documentation like this CI file is like over a year old.

A

So like things change in gitlab the product, um but generally speaking, it's pretty much backwards compatible so um and there might be Nuance there. These might be separate. I just don't know off the top of my head, um but this is a good example to your. Your fine broken links thing. So the script is just yarn, fine, broken links, and this is kind of nice. You can like bundle anything you can Version Control into like a shell script or a JavaScript. Anything can run with yarn.

A

You know it's kind of nice because then you can say um like cool like I um uh like. If yarn can do it, I can write a script that just says yarn. Do this thing what it does do is it suggests that you know when you see stuff like this, you should consider going into the. If you don't know exactly what's going on, you might consider going to the package.json file and there is so yarn find broken links uh as it runs. Node scripts find broken links, Dot modulejs.

A

So then you would go into the scripts file so like if you want. This is like how you dig into what's going on. Nathan knows this because he wrote this um but like this would be like you know it can be a little unclear.

A

You know, you'd be like okay like this is a one-liner, so it can obfuscate what's happening, um but because it's yarn, you can use yarn to like follow the breadcrumbs and go see what's actually being executed in the container right um so up next, because we're kind of I want to focus us back on deployments um because that's sort of the the major uh stuff here and there's a little bit more nuanced. So then you get to the deploy stage.

A

You see it needs build to have been done and it also will have its own artifacts. We need that for how it's going to actually deploy, um and so, uh where are we what's? Okay, so we set some variables um and basically like uh there's comments here, like this variable, is used in the scripts, deploy bash file to switch deployment, logic um and it'll create review app, so those review apps that get named based on like the branch. This is how that happens.

A

We give it a name and we give it a URL and it gets this environment variable. That's the commit ref slug, which is like, if you name a branch, say like git check out Dash B name of my branch in gitlab, the CI commit ref. Slug is name of my Branch right, and so that's that's all. That's that's the magic of review apps! That's that's just how this happens right and then we, basically, we literally just move so like the um artifacts like to get to the review app.

A

The review app expects just like conventionally, like any web server. Typically like the public. Folder is sort of like what gets. If you go to the like, like Apache, expects a public folder to be the thing that serves up your index file, so we just move just the command MV um the program MV like dist to public right, that's all, um and then we and then we run a deployment script um and that again to follow the breadcrumbs.

A

um We have a little script and look at that. There's a deploy script here and this is a batch script um and look at like last I changed like nine months ago. Right- and this was like we were adding some additional compression um and then so. There's a bunch of comments here about stuff um yeah. There are places that can fail and we exponentially like back off and it's bash, which is like annoying right.

A

Like you know, if you're not always writing bash, it can be like uh what is this right um uh and so there's like a batch function. That's just like helps. You do exponential back off when things start. Stop working and you'll see this in the log. So like these Echo statements will end up um where's my deploy, you can go and you can actually see what's happening here. um But uh oh, this is the pages deployment Pages doesn't run the script um production deploy is the the one yeah a lot of copying of files.

A

Starting deploy for production app and- and this is where that variable comes in it's like- is it production? Is it review um and then so? Here's where these environment varies, so this is sort of like is where all the rubber meets the road. That's how it gets. The internet hour of everything at about.getlab.com is hosted on a Google Cloud bucket.

A

um That bucket is there are there is like an ID for it, a name for it. There's some tokens that allow us to like push to it right. Those are all hidden in gitlab, CI I, obviously won't show them on this recording. But that's how, like these things are, are coming through here right and that's- and this is again it's like the security aspect of like that's all private and like Forks, can't get access to that information, um and this is really just an if else statement right like it's like for review.

A

Apps we go to the review app buckets per production, we go to the production buckets and we have these different auth keys right um and a few different, um and this is all like Google um Google command line tools, specific stuff in terms of like excluding certain things um and that's the magic. The the trick here is.

A

um This itself is straightforward enough to like read through that read through bash and look up the commands of what's actually happening. If you want to know like what happens on the on the container, the thing that is unclear and is not like immediately like obvious, if you're just looking at this- is that there are two repositories, two different pipelines that push to that bucket. One is the buyer experience repository. The other is the www.getlab.com middleman repository they're, both sharing it and we actually use a command. uh Where are we?

A

um We use rsync, and this rsync command is basically it like it's smart enough to figure out to overwrite right with like the most recent files. So you can. There is an order, dependency here and like each one of those each one of these repositories. Pipelines has the same level of access to that same bucket.

A

We have just conventionally set it up so that they don't conflict and basically the idea is that, like in the middleman repository, there is an additional script that will pull the most recent artifacts from the most recent pipeline here and bundle it together and we'll redeploy so like the buyer. Experience repository will always deploy its built files to the Google bucket and those will always win and update. The middleman repository will always pull the latest.

A

So if you were to like make an MR and buyer experience and update the home page, that'll get that'll just happen, like we've all seen that a million times it just gets updated. If someone then goes and updates the handbook in the middleman repository, the home page gets updated again, but it gets updated with the most recent build and that's why the um that's? Why there's an important stage here um this Pages deploy has its own artifacts and the pages job gets an APA like there's an API request.

A

You can make to the gitlab API to get the artifacts from a particular job, and so the middleman repository just so happens to know the API endpoints to get the artifacts from this job and it will get the most recent one. It won't make any modifications it will just get the most recent one. It'll bundle it together and so, at the end of the day, that middleman site always rebuilds 100 of everything and pushes itself to the Google Cloud bucket. The buyer experience website does not pull in from middlemen.

A

It only pushes itself to the Google Cloud. So there's some duplication here, but like it's a safe form of duplication. The thing that bites us sometimes is that the middleman script is not smart enough, like like I, think you could do this I just didn't because it, but it won't um remove files that were removed right so like it will, and there is a cleanup script somewhere, but like there, there is a possibility that stale files, like stale files, that middleman doesn't manage that get removed from buyer experience. They won't get moved a fire.

A

Experience has like removed them like they won't get pushed up there, but you may have to go in and actually like, like like delete the files in some way. So there's like a little there's like one small there's, one scenario in which you get some stale files and I.

A

Don't think: we've seen that in the last eight months, I don't think that's actually been a problem um because you know because of it, but the only reason it's not a problem is because of the human processes, because we've moved so much of our development over into the buyer experience repository. If we were really splitting our efforts in both of these, we would need to be a lot smarter about these deployment processes.

A

But for the most part, the only changes in the middleman repository that ever get made anymore are under the handbook and the buyer experience repository has nothing for the handbook right um so like that's like it just works that way for human processes, not for any technical reason, I think it's really important to call out that, like you could get into some weird scenarios if both of these were being actively developed against the same Target deployed pages right like you, don't want to maintain a home page in both right.

A

It's it's kind of important that each repository knows what pages it's responsible for and while they are unlikely to break each other's Pages, they could end up in a challenging scenario of like who wins and like the best way to mitigate. That is just never let them serve the same page.

C

Okay and so I have a question for you or a couple left too yeah, um one of them being one day. Hopefully, um when buyer experience kind of migrates and the market site migrates out of the repository, what does that migration look like like? Can we just shut off www and everything will be fine and now exactly.

A

No, um there are for legacy for historical reasons. um The middleman Repository I mean primarily uh I, think the biggest risk that you have is the redirects file, which is all handled. The thing is the redirect file is written in it's basically there's a ruby script that, like um so I forgot, there's one other step of like so. This gets deployed to Google Cloud bucket people, don't just directly access the Google Cloud bucket.

A

We use fastly as a CDN fastly reads from the Google Cloud bucket and like serves up when people hit about.getlab.com it like serves it and it like caches it, and it does all the smart things there.

A

The original middleman repository has a bunch of utility scripts that manipulate the fastly API, and particularly the important thing here is the redirects API, so like I, think we've I think the three of us here have probably at some point written redirects and that redirects.yaml file um you could move that logic over to the buyer. Experience repository I would strongly caution that you do not right, because it would just be a lot of duplicative work for something that's already well understood, well, documented and working.

A

So what I would say is you don't necessarily want to deprecate the repository, but like my vision for what that repository should be, if handbook leaves it like, the handbook is gone and we're gone like that. Repository in my mind, should become basically a like an infrastructure as code repository that, like for legacy reasons, is much safer to just keep those configuration scripts in Middleman right, like that's, that's I, I think that's the way to do it. I mean you know.

A

You might conceptually disagree with me and over time you may say, like we want this all in the same place, um I personally as a person working at gitlab I, don't think there would be enough business value to justify the headaches of migration. um It might feel nice, but this is one of those things where it's like.

A

That's a feeling and not like a reason um so like I, think your lives will be easier if you, if you keep it alive because it's gonna cost you much to keep it alive, especially if handbooks out of there and then you say: okay like this repository is now like a dozen yaml files that like it, that that do something that that have some side effects to them right um and then you re-take it over as the team that owns that infrastructure and that's just where you go to do it and like again, maybe I'm wrong Maybe I'm Wrong in a couple years, and- and you really want to like streamline stuff put it in the same place, I I.

A

Don't think you gain enough for that to justify the risks of migration, um but I again I'm willing to be wrong on that. And uh you know it's not my problem starting Tuesday so but yeah, if you don't just shut it off, um do not just shut it off. That is a dangerous and destructive action. I! Don't think anyone would do that without really thinking it through but like um it is not just a static site deployment. It is many other things for legacy reasons. The redirect file is the biggest thing and I will say.

A

The nice thing is: if you delete it, the fastly redirects will just stay at their current version. You'll just it will just be much harder to put in redirects and I guess that might be another way you think about it is like well. Should we even be controlling our fastly redirects from this yaml file?

A

Maybe the thing we should be doing is directly interfacing with fastly to like do that sort of configuration work, and maybe there should be some some separate repository that is built where the primary use case of the repository is your fastly configuration and it has a set of utilities for that. That might be the way to think about it.

A

um That's up to y'all and my team, like there's, there's plenty of at that point. It just becomes a decision making process so um anyways I, you know I I, wouldn't lose a ton of sleep over it. One way or another I I personally I think I've never advocated for making that thing go away. It would never be if I was working here for another three years. It would be the last thing on my list.

A

I I, just like wouldn't want to do that and I would recommend people like really interrogate if they want to do something like that like. Why, like what business value are you getting to deal with all that risk and work versus just working with something? That's basically fine right and like doesn't cost us money to have that way. So um so.

C

Yeah and then during the gcp bucket, so yeah.

A

It's yeah, it's just fine! um So that's that's my thought. You, you I, think you should consider over time deleting like that repository should get Slimmer and Slimmer yeah to.

C

Go away totally.

A

Like those are the sorts of things and that may even be a destructive action, you may find that you lose some web pages, but, like we've talked about this before that, there's a little bit of healthy pain of like like rip off the Band-Aid on some things and see if anyone even notices about pages that are getting basically zero traffic right like that would be a thing like you should that you should still like go about with some Care on that decision and ask yourselves again: why are we doing this, but I do think, there's actually a good business reason to like reduce the noise of like, what's being maintained, like I, think that that actually helps people make clearer decisions and, like will help expedite like the appropriate migration to buyer experience where it ought to be or to new handbook where not to be I.

A

Think that's a perfectly I think. That's a good idea to do. um I would just you know, make sure you understand the implications and just like go about it somewhat carefully um and don't just rip out the whole Repository.

C

I have uh one last question going back to kind of fastly, and now we have these two repositories that are essentially just copying files over to the gcp bucket and being served by fastly. How does fastly know there's only one entry point when you have two like how does that merge together? There's.

A

Not two there's so because of the way the rsync works so.

C

B

A

Go like at the end of the day, there's only one file that is slash index.html in that bucket um and by our experience, always wins, because either buyer experience repository pushes to it or the middleman repository pulls it in. This is a point of confusion, though, if you run the middleman site locally, there is a home page and it's probably six months out of date, because there is in fact, so.

A

This is another thing where it's like: there's obfuscation happening, but it's low risk and again you gotta ask yourself how much you care, especially if you're, not in that room. If we're getting out of that repository for many, you might delete it, um but anyways. If you run like the local middleman server, there's a home page that home page does get built in the pipeline, but because the pull step you can think of it about pushing a poll.

A

Buyer experience always pushes never pulls middleman holds by experience, pushes up the resulting merge and because it pulls by your experience after it's run, the build build step- and this is on the CI pipeline for the middleman site.

A

um The index.html page that gets pushed up from the middleman job is actually the next index.html page right, and that is the one that wins um and like this is, and this is again why like generating- and this is why doing the static generation for nox is really important, because because they share the same output, Primitives, both middleman and next, their generator steps, their generator static generation. Only three types of files- HTML CSS JavaScript- they don't know anything about view. They don't know anything about react.

A

They don't know anything about Ruby right they're, just like plain web Primitives, HTML cssjs in a file that can be statically hosted and because of that they can push and pull like that and they they can speak the same language at the end of the day like the next files are just index.html and then there's JavaScript, bundles and there's like some conventional stuff about like, but but at the end, but like it's all convention around these three technologies that both of these, that both of these um programs understand how to Output right.

A

So that's that's why that works. That's that's the beauty of the static site generation, and so, if you wanted to move away from doing static site generation, these things could not live as nicely together. You would have a lot more complex deployments to say, like if you're doing partially static and like partially, like server-side rendering ring right like that's, that's just a whole different architecture.

A

Right and if you do find that you're going down the server-side rendering route for reasons, then you might consider like just dropping all support for middleman, like I, wouldn't try to shoehorn in that process, but you'd also have to like understand that you're, basically totally Divergent like what we did a year ago, when we put together this pipeline was we said what we want to do. Is we want to stop like having to play by the middleman rules and do things with middleman way?

A

We wanted to lean into a JavaScript first way to get to that static site output, and because we agreed that we would still be doing static site generation that opened up the avenue to maintain these sort of like these two repos pushing to the same Target, and so that's a huge virtue and allowed us to move very quickly.

A

We did this project in like two or three months, total like I, think we did it in a quarter and then it's just and it just works, and it's just people don't like I, don't even think about it anymore. So like it's really really good and then, if you're changing the architecture, you like you, you lose that you don't lose it entirely but like to keep that backwards compatibility.

A

You have to do a lot of extra work and you might consider just like just a clean break right if you're thinking about static side, server, side, rendering which is different than the static generation, there's good reason to do service documentary. um There's a lot of performance benefits um right, there's also sort of like a cultural shift back to server-side, rendering there's some good tooling, uh very particular.

A

You know we're doing more and more a b testing and all of our a b testing has to be done on the client side and that's like a performance um hit for us. It's it's not great uh and server side. Rendering would allow you to do a b testing at the server level and, like not experience the same um uh client-side performance hit right, but it's also like more expensive.

A

It's like there's a lot more moving pieces like you can't do like you can't just slap up a server, but our traffic is such that, like you, can't just provision one server and do server-side rendering like you need a lot more, um so you know I I, think uh uh I I wouldn't mess with what's working, but there are limitations like like and I think the a b testing is one of the places where we really see a lot of limitations, and even like you know, some of the view stuff we're doing is like a limitation to the static site to the static rendering like there's just there's a couple of play, but like we made those trade-offs a long time ago um and they've been reevaluated annually for years, and it almost always comes out ahead.

A

That, like doing this, is the appropriate choice for what this website is and I I would I would be shocked to find that, like that, that wasn't the case in the next two to three years. um But again you know uh uh not my problem yeah. If someone else feels strongly like yeah, don't like don't watch this video and think that you're wrong, you obviously like, if you're watching this in even two weeks time, you officially know more about like what's going on than I.

A

Do so, like you know, use your best judgment but like maybe this will caution you from um architectural changes.

A

B

A

Feel like we covered everything, do you have any like other questions, either specific or general.

C

I think I'm good from my end, yeah well.

B

Like the overview was great, like you were answering my questions as we were going through them, so great yeah.

A

um You know, like I, said: I I, don't expect, there's another thing like as a as a yellow flag right like if you find that you're making a lot of changes here. You should ask yourself why, um like this it like it like the last time, I touched, the deploy script was nine months ago um for I. Think what was a one-liner change uh and before that it would have been like 12 months ago, like it should kind of feel easy.

A

It should kind of feel like magic, I think it's one of like, like I'm, very proud of it, because it has served us well over a tremendous amount of growth, both in terms of like team, size and scope of website so like if you find that something is weird about the deployment like I just I would be shocked to find that this is your real problem you might be approaching, and this and again like to go back to like the um a b testing like a b testing, doesn't work well with this right and like if you like, like that is something where you might say like I'm having a hard time getting the A B test to perform the way I expect them to using our deployment process.

A

The answer is not to like make this deployment process more complex. It is not to generate the site three different times and deploy them to three different, like you could do that. That is not the answer. um I like I'll, like I'll, give you the hint. That's not the answer. uh It's like I'm feeling pretty strongly about that.

A

That is a moment where you have to ask yourself, like you know, do the benefits of doing a b testing through server-side, rendering like outweigh the cost of like changing the art like like there are just some things that are easier to do with different architectures than others like that's. Why you make these choices?

A

um We weren't doing much a b testing at all when we made this decision so like, if that turns into like the primary thing that we're doing on this website, I could see that the team might say like we need a server that can resolve these a b tests and like ship. These variants, like on a smart computer really fast and serve that without making people's browsers do a do. A fetch request to find out which version of you know what text to put in a button right, I think that's actually a totally valid thing.

A

I would never expect someone to be able to solve that problem in the deploy script. um I guess I've ever seen ever but like that if you're I just think you're barking up the wrong like again, this should feel easy to work with right. You should be able to be like, oh like are we talking about like? Oh, maybe your test script? Maybe you do want us to depend, maybe you don't want it to depend? Maybe you want to change where your artifacts go?

A

Maybe you want to like try a quick, optimization on a thing or two or like you want to add a script to verify some output. That stuff should generally feel pretty smooth to do. It should feel anything I think you can speak to this of your 404 Checker like it didn't feel like you were swimming Upstream right.

A

It was like you write the 404 Checker you put in a job, you kind of like look at how the other stuff is structured, and you know you try it once or twice you clean up any weird bugs and then you do then it's and then it lifts and it's working. So it should feel like that if it feels harder than that I think you might need to rethink what you're doing.

C

Yeah 100 agree at the end of the day, like we have a static site, we don't have any like user data, we have no API and so I don't see any to ever switch to server side even for disability. You know I think we can get away with it and at the end of the day, like I I hate to say it. But it's simple like we have a simple site. We have almost like a textbook, go on like code academy and do a static site, whatever uh the.

A

One thing that is.

C

A

I'll disagree with you in one aspect, which I think will change over time.

A

um I think that our website that this website is particularly the middleman, a little bit less the buyer experience but like we are pushing the limits of the build times like if you think about the, if you think about the sweet spot for static site generation, I think that we are well beyond the number of pages and sub pages and like components and stuff where, like to some degrees like changes in like server side rendered um websites like like we just.

A

We have such a volume of content that, like I, think you're beyond the ideal scenario for a static site generator. But that was true two years ago when I joined and it's getting better as we like scope down what the website does.

A

But this is the thing where you need to be careful because, like you know, this iteration of this team has in their heads like culturally, that, like we're, trying to scope down the website into a smaller use case, it is for I could see someone in a year when things change that the scope is expanding and if the scope starts to expand, there's going to be like a much stronger case for not doing a static site generation and I think that if we hadn't done this thing to like like run away from the middleman site- and we hadn't been on a mission to like reduce the number of pages middleman spit out like we had we had for years, but basically Beyond The, Tipping Point of how much time it made sense of how many pages it made sense to statically generate because there's like 13 000 or something like that.

A

I think that's way in the middle of man, say and I think that's well beyond um any happy path, and even the creator of middleman you can go and like Google. This about, like that, like gitlab, has been in conversation with the middleman, because they're open source and and we love them and they're great and I. Think there's like even a Common Thread, where, like the creator of middleman, was.

B

Like whoa, like.

A

I did not mean for an 8, 000 page website to be running on my thing and I. Think that, like that's, that's important context, it's something to think about and I think next um had some benefits, there's some incremental regeneration. They like there's some approaches around it, but like there are trade-offs of static site, gender static site generation and one of them is if you have a ton of dynamically generated content and you're, and you know it's going to grow, you might start thinking about a different approach.

A

um I, don't anticipate that for this team, but like if someone is watching like years later of this video, that would be a thing to think about.

C

So when we, we think about the blog and we think about the release posts where we're looking at thousands of additional Pages like, is that something you think next could handle, or is that.

A

I don't know um it's like it's so much on the on the it's like Towing. The line in so many.

B

A

That, like it because like like, you really don't want to do those they have like a static site and then also this like Surfer for server side, like it's kind of like you kind of want to pay the price there and it's uh I, don't know I I, don't know. Oh no I do know um what I may consider is another static, another static site generator.

A

That's like another next thing that, like the way like that doesn't get built every time this website gets built because you know presumably blog and release posts have a totally different release cycle and so like they only need to update when they update you don't need, like you, shouldn't necessarily rebuild your whole blog folder. Historically, every time you update the home page, but that is what we do right like or well.

A

No, because it's a middleman, but if you move Vlog over that's what would happen so you might consider like a third repository like you might actually consider splitting it up and saying this is the blog repository keep it on next? Keep them in sync as they're using the same technology, but like their build step. Is differently or you don't even need a separate repository? Actually you could like sorry. This is it gets where, like every one of these things is like the cleverer.

A

It is the more complex it is and the harder it is to like um keep it maintained. But, like imagine that you cached it or Matt, you could even say, like you, even have the the blog generation step. So one Repository, you change your yarn generate command to use different, ignore files, and you say, like okay, yarn generate blog, only generates all the blog posts.

A

Yarn generate, generates everything but the blog posts and in the gilab CI you can actually see what files change and you can use like file like lobbying paths, and so you say, oh you know generally use yarn generate. You have to make sure that you keep a latest blog right. You have to like it's like yarn, generate and then go make a curl request to like the latest artifacts, the last Good Run Of A Blog pull down. Oh you!

A

Don't even do that because it's all living on the Google Cloud bucket yeah you're, going to do that because it's all just there in your Google Cloud, so just generate all the new stuff like skip the blog push all the new stuff up. All the gcp Google Cloud Storage stuff is like still there.

A

You only need to override the blog files when blog changes, but again, but you're you're, moving away from the convention so like you're, not just running yarn, generate you're running a two new commands that are not directly supported by next you're, like configuring, you're configuring away from your convention, um and that's like a you know that, like sure you can write a markdown file about it, but then everyone needs to know that markdown file exists right, like you start to add a bunch of questions, and so you have to ask your like yo, you might Benchmark.

A

How long does it take for blog posts to get generated? Is it 30 seconds? Is it two minutes? If it's two minutes might be worth it um 30 seconds? Maybe not, but it is going to grow so I. You know I, think those are questions to ask yourselves. You have a lot of you have a lot of options and they range from like many additional projects and like a a complexity of the like a a general, a breadth complexity of like all the different projects.

A

You have do a depth complexity of the the very like Niche things you're doing inside one place um and I, don't know if, like I, don't know if there's a third way that gets you away from complexity right, it's just like I think you have to choose which type of complexity is the right choice for the team.

C

Oh yeah I think that's it for.

A

For me, that's.

C

A question I know: we've been going for a while. um Is there anything else we want to kind of add at the end here before signing off or do we think we got everything so.

B

C

We drained all the all Tyler's.

B

uh My lifeblood I have an open question.

B

um Is there anything that and I mean like you might not know the answer right now, but like is there anything that you can think of that, like in six months we're gonna, say man? We wish we had Tyler to like ask this question.

A

um Yeah you're gonna want to know how to uninstall my crypto Miner.

A

That's a good question. um No, this is the. This is the one thing that I was on my mind for the most part um I most of the work that I've done in the last eight months has actually been outside of this repository working on, um like Google analytics in the product uh working on something like a b testing a little bit and like um yeah I think this was the biggest thing where I was like I, don't know if I've ever really sat down and talked with someone about it, I have written it down.

A

I think you could go, find, there's documentation on this. It might be a little stale, but also this hasn't changed much so like it wouldn't even be that stale. um This is the answer to your question.

A

Like this conversation, is that um I think everyone else on the team has done much more in terms of the actual pages and components that I have in a long time, like I, think those things have done, the teams have done a really good job of, like you know, expanding the responsibilities to new people um and and people have done a really excellent job with it.

A

So I think this is maybe the last Bastion of like what lives in my head and what I think people would want me around, for um there is stuff in the product there.

A

There is sorry there's an additional answer, which is um the stuff that we did all the Google analytics instrumentation for in the product um and I think that's going to be tricky to detangle because, like our team doesn't have a ton like I've spent time Miracle with you with Javi, with Lauren, like uh with Justin like I spent time talking with folks, really because it's just like not the core thing that our team does um and so I.

A

You know I think, there's like a real challenge of like figuring out how much more this team Works in that code base and like yeah I, think that's I, think that's the real thing. um But it's you know the nice thing and it's under degree is like it's also not this way like, like neither of you, are necessarily responsible for that right so like for for your day-to-day no, but for like the broader team question of like those analytics I.

A

Think, like that's a harder question to answer, um I don't have the answer to even if I was sticking around for six months, I think it's a business risk to be in there anyways, with just like one or two people on this team who have the expertise to do so so, like um you know, I think. That's I think it's always been a problem um and I don't know I, don't know what the real answer is.

A

So cool! Good luck, don't need it. You know, you'll be fine, it'll, be fine. uh No I think it should come along pretty smoothly for you um and I credit that to like good product in gitlab. Right gilab made this easy to do so.

C

Well, thanks again for for having this video and sitting down and chatting with us, but yeah.

A

C

Setting up that next, repo in the past yeah.

A

That was fun. It was a fun time. I had a good time doing it and I'm, just like, like I, said I'm very proudly, I'm very personally proud of like where it's gone, and uh how useful it's been for people and just like it's it's just it just kind of works like that's.

A

Why, like that's, why I want to bring this up is like we've had so few problems with it that, like no one's ever had to troubleshoot it they're like it like I I, always expected other people to jump in and help out, but there's there's been almost nothing to do because it's been great, but it doesn't mean that it always just worked for you right, like you'll you'll, you know the um the container images you use right are pinned to node 16.

A

So when you upgrade past that, like you'll need to think about updating those things. Oh there's one tricky thing: ah yes, I'm glad! There's one tricky thing, ah there's a note about this.

A

um Our deployment image um hold on. Let me.

C

Or, were they different between.

A

There's one image: so you gotta be careful of.

A

B

A

Deployment image look at this comment. This is important, um there's even there's a couple uh Mrs linked to it, but basically um we use gsutil, which is a Google Cloud utility. We use a patched version of it that one of the staff engineers at gitlab patched and that's baked into this image we could make our own, but basically like here's like the www gitlab repo, like image. This image is required for our deployment for like one particular type of command um and there's some Mrs.

A

You can dig through to see the why this will basically always be stable, but this is a. This is a. uh This is a this is a thing to watch out for and that's why? There's uh four line comments around it so like just like your deployment image is not just a node Alpine image right, but it's only for the deployment job. Everything else can be done. Node.

C

And this is because of Middleman.

A

No, no, this is, for other reasons, this.

C

A

Google Cloud utilities and like um there's an option, uh basically like what you should be able. So ideally this image for deployment, because we only use the Google hot SDK. You should actually be able to use the docker image. That's the Google Cloud SDK. You should even just be able to use latest, but um we use a because we want to gzip the files for performance reasons.

A

um Stan had to patch the GS util package to allow for a particular argument to be passed in right.

B

A

To use that patched gsutil, we can't use Google Cloud SDK latest this patch gsutil is just being pulled into here. It doesn't have to be pulled into here. You could pull in that patch to another Custom Image I never wanted to mess with it because it kind of just works, but like this image itself has like it has like Ruby into it and a couple other things that just don't get used. The thing that matters is this patched gsutil file and there are specific Mrs that point to the patching.

A

The other thing you could do too is like, if Google ever patches, gsutil to to pass that flag appropriately. You should be able, like the ideal say, is eventually you come back, and you swap out this registry.getlab.com link for Google Cloud, SDK latest. That's what you want to do, but until that day um just be careful, don't you know don't mess with us.

C

But I'm assuming this is like dog site like this, is not just us. That's using this image like I.

B

A

Know: okay, fun, okay, so that may be a point of Investigation. That's another one. I was kind of just like that's a little bit of duct tape, holding things together that, like I'm gonna, remove that I just I just wouldn't want to mess with it. So um you know that's.

B

A

Like it's like I, just, don't think, there's a lot of value for the business to be gained by you like it works. It works fine. We know why it's working. um That might be a a a a pet project. You do in your like 10 Improvement time, but even that there's like some risk there, so um yeah. So, okay, that's the last thing cool anything else.

B

A

Golf all right, I'ma stop the recording, thanks for watching, thanks for being here.