how to deliver end-to-end like a Senior Dev

It all starts with some code on your, let's say, machine. If this is a front-end, I would assume as a by-product, as an end-product of this, we would have some JS code. What happens next? You'd push your code to GitHub, let's say. Somehow it'll end up deployed in Netlify, right? Something like Netlify or Vercel, or whatever, the one-click deployment. But again, this will make you look like a junior.

So if you if you go ahead and interview and you say this. So, what we will focus on here is how would you do this for a real professional company and for an enterprise. Let's go ahead and start over. We're going to get get the same model and say, okay, we do have a code base, right? We have our React JavaScript app. Now, as a result of this code base, we need what we call an artifact. I'm going to put it here. When you're working alone, this can be like the code you have in your on your machine that you push to to something like GitHub.

Or when you're working in a team, this can be the the code base that everyone is pushing to. Yes, so basically you would have some sort of source control, right? That's your GitHub, that's your GitHub repo, that's your GitLab repo, that's your whatever repository. Most companies use Git nowadays. But this is where your team pushes code in this first control. Really important, when it comes to organizing repositories, we have certain Git flows.

And one of them, the simplest, would be the trunk flow. This comes from a c real where you push everything to master. Then you have feature flow. This is for a mid-sized team where we all like switch to a feature branch. And then we merge that, we open a pull request, we merge that to master. And then for complex enterprise, you have things like Git flow. So that's your code. And these are the three things you need about managing code in the source code.

Also make sure you know like what a pull request, which is basically a request to pull from the main branch into your branch, which will end up merging your changes. I mentioned the artifact, and this is where I want to ask you a question that is, what would you say is the artifact for a React application, for a front-end? An artifact, it's deployable version of of the code base the javascript bundle that is also webpack or whatever module bundle you are using. Perfect. But of course we also need some index HTML and we have some CSS files. So in the front end it will mostly be this, but let's be very complete and add fonts, sometimes we might have images. That's our deployable version of the website, all the assets we need. For us to get there, to get from source control to the artifact, there are certain number of steps that need to happen. And of course you can run those steps manually, but normally we group them together into what we call the build pipe. And so here what would you say? Going from, you know, react code to the artifact. What would you say? Imagine we're building a typescript application. What would you say are the steps we need to go? We would have a, you know, typescript compilation phase. Then we would have the webpack or the module bundler compilation as well. And after that's maybe static assets like images might have to get compressed or rotated in a certain way. Yes, perfect. So, we'll compile our typescript, we use webpack to polyfill our code, we might do some code splitting. So, the module bundler will go to minifying the code, it will compress our code. But we'd also might want to lint our code. We don't want to build any artifact that doesn't fulfill quality standards that we might have. And of course, we might also want to run the unit tests. So, this would be our build pipeline. This is the first thing you want to get good. And I invite you to run these things manually. But of course, in a modern team, you'll have a CI CD platform doing this. Just to clarify the order, what would that be? So, I guess we lint first, then we unit test. Then we TS compile, and then we webpack build. If you want to make this in order and then yes, because it doesn't make sense. To run a build, which is very expensive, if we already know that the code doesn't lint, and it doesn't make to build or compile something that doesn't pass the unit tests. So, it's better to do those first. If they don't pass, the build, the pipeline will break, and the developers usually get an email. Hey, the pipeline is broken, you need to fix something. We cannot move this forward. This is not the best

quality artifact. All this will run into software that traditionally used to be Jenkins. Now we have GitLab and uh if you use Heroku or I mentioned Netlify, they do all this for us under the hood. So this always happen uh Jenkins, GitLab, you have GitHub actions that can do it nowadays. So then we have our artifact and this usually gets stored somewhere in our CI CD. It gets stored into what we called the artifact repository.

Now, you don't necessarily need to have this, not all the companies have it, but professional software companies will have it. And we've seen a second why we need an artifact repository. This is basically versions of your applications. Pretty much all you need to run your application with different version tags, usually, we use the commit ID. So, the commit hash to to to to to to to identify them or you could have a versioning, like semantic versioning, something like that.

And they stack up on each other. So you can get the latest. Okay, I'm going to put it here so we like the one and this is basically our artifact repository. And this is when we move on from the build pipeline to actually our deployment pipeline. So I'm going to add it here, this will be our deployment pipeline. At what point do we spin up a pre-prod instance and run our end-to-end tests? That very much is a choice of the team.

There are teams that do it on staging already, so we have like a stage. There are others that do it after the deployment. So because it's a bit of a smoke test or a canary test. We can talk about it once I layout the deployment, but it's very good question, probably you want to have them running on the staging instance to. Really important, the deployment pipeline can have different destinations. So you could deploy to staging the which is usually like an acceptance test for for product to see what we built.

Or it goes straight to production in a very much way company. Only very, very mature software companies, very good engineering teams can do that because they actually have the confidence that they don't need to go to an intermediate stage and do manual testing, which means they have a lot of automated testing so they can go straight to production. That would be what they what they call continuous deployment. Most companies don't do continuous deployment because they don't have the coverage, the test coverage to enable that. They just do continuous integration, which is what we've seen so far. This is what they call CI, that's the continuous integration pipe, which is a way to continuously integrate your changes. This is very important because if you're applying to jobs, you will see companies repeatedly asking for a CI CD. In the same way they ask for unit testing. Don't assume they are actually doing it, but do assume there will be questions about it during the interview. Exactly, they will ask about it even if they don't do it. So pretty much this is it. Then we go over to deployment pipeline. Now it depends where we deploy application. I'm going to make a couple of assumptions for your mid-size software company. In the case of client application, you'd probably use, let's imagine it's a static application. Well, we can deploy to actually even to S3, like static store. So this would be block storage, this is like a folder, a little folder on the cloud where we upload our assets. So that's our S3, we store the application there. And then maybe, if you want to be very professional, we have a CDN that will stay in front of this. So we have a CDN, a content delivery network that will basically distribute, like it takes our application from here and distributes it close to our users. And our users actually go here. This is where the users actually come from, and I'm going to put here users. Perfect. So we upload everything to static storage. And there might be different steps we want to do there. So right now, if we look at this deployment pipeline, what would be the steps? Well, basically, it would be get the latest artifact, in this case, just the folder artifact, upload. Or sometimes the one we tagged or the one that development team agreed to move towards the deployment. Exactly, so you might have the case that you need to do a roll back, so in that case you don't deploy the latest. You just deploy a specific version. And this is the advantage of the artifact repo that they can always really quickly go here and be like, hey, I want actually this version. Not

the previous one to be deployed. If you wouldn't have that, imagine we don't have an artifact repository. We need to go all the way up here, revert the commit in source control, go through the build pipeline, and then finally be able to roll back, which takes which takes a lot more time and it will generate downtime. That's why this artifact repository allows us to say, oh, hey, something happened. We deploy this version or the previous one. So that will give you less less downtime. But basically, in this simple setup, we get our latest artifact, we upload it to S3, and we refresh the CDN. It does that automatically in uh in AWS, we don't need to touch anything. And that's pretty much it. That's how we deploy the latest part. And as you mentioned in the beginning, we might want to run some sword of end-to-end test. Now, this deployment pipeline is the same if you want to deploy to either staging or production, which is our official version of the application that people used, or more newly to some sort of feature environment. You can actually spawn there there are tools that allow you to deploy your whole infrastructure for a specific feature. So you can have different versions of it live on specific domains. And whenever the these features are approved by product, they get merged into product. Understood. Okay. Does it all make sense so far? Yes, it's all clear. One thing I wanted to talk about is the CDN part. Just for people watching us, if you're not familiar with CDNs, it's basically storing a copy of your static assets of your whatever you have in the static storage, storing it in different nodes, and those nodes, the only difference is they are closer geographically speaking to the user. Right? So for example, if you're in the US and your servers are in the US, we the CDN will distribute some copies to Australia, some copies to Europe inside locations, which will drastically improve performance for static assets and one thing I wanted to ask you about what is the difference between, you know, static and dynamic in this case? What what do people mean when they say static storage?

is static assets in the front. We have all these different edge locations that the CDN copied, a copy of application, and they get get elected user based on latency. They have a latency table and it's your IP and they're like, oh, it looks like you're going to have less latency to this instance and you get there. When it comes to static static assets, these are basically files. A website, it's mostly made out of static assets, HTML, JavaScript, there's no CPU, there's no need to execute anything. You get those, you download them in your browser and your browser does all the compute power. They interpret it. So in the end a website or a SAS application, any client application, it's just a set of files that will will execute in your browser. So we can just store them on a CDN, a cloud folder and you get them from there. That's static. Which is getting amazing because you can cache those things, you can store copies, you can distribute them. Now, if you would need dynamic data that you need to make a round trip to the database, get some data, do some operations on it in the back end and then send it back, then things get a bit more complicated, right? You will have all these back end services. But for now, I think the point of this video was to focus on a front end deployment pipeline. Is there anything else you would like to underline, Bogdan? Talking about dynamic and service, we in 2024, we use a lot of server side rendering. And when we introduce server side rendering, everything changed and we can actually copy this and let's see how it changes because you mentioned something very important, which is when we have server side rendering, first of all, our IP fact is not anymore only the static assets, but it's also some node JS server code that has to be executed by a node JS server. So all of a sudden, all this, all this CDN doesn't apply anymore. I will copy it, nevertheless, but we will change it because it doesn't really apply anymore. We cannot use static storage anymore. We need what they call compute. We need a computer that can actually receive requests, process them.

and you turn something. It's not that removable. You make a request, I give you back a static file. The simplest form of compute, it's a virtual server. A virtual, like it's a server, but nowadays we use virtual serve. Which means we don't own the server. We don't have a computer at home. Tell Amazon, can I rent a computer from you? And the simplest version of that is EC2, which if I'm not mistaken, they actually use a couple of those in your past position.

So basically, let's let's reconsider our deployment pipeline. We still get the latest artifact, but we cannot really upload, we don't upload history. We might need to upload some static assets. But for now, we will need to somehow push or pull, push or pull the new code to the server. So let me remove this to the server. And because we usually don't push our node modules because they are too heavy, we might also have to do an NPM install after that.

And then we need to restart, restart the server. Now, of course, sometimes you might have secrets, you might have database credentials that you also have here that need to be pulled. So we also need a way to pull credential. If you are working for a big company, they might have something that you maybe heard about, which is a secrets manager service. That means you could connect to there and get passwords and sell this service.

So you don't need to high code those things in your code or in your source code. But ideally, you need to do all this and then restart the server with a bit of a downtime to have a minimum deployment. This would be like the the most basic deployment. But this is something that you might found all the way to 2005, 2010 is not something that professional companies would do today, because it has downtime.

You've probably seen that we restart the server, so there is downtime. So what if we don't want downtime? How would we go about it? If we don't want downtime, there's different ways to do it, but you probably will like to move towards a different deployment. The one I discard here, it's also called in place deployment. There's different styles, but A deployment without downtime would be a blue green, for example, and I will uh blue slash green, right?

And I will simplify this very quickly. But basically, whenever you deploy, you have, let me draw it here, we have a old server that's still receiving traffic. So our traffic goes to the old one, and then we recreate a new one. We create like the new version, and we create a new server that has exactly the same specifications. But we deploy and we know that the application is up and running here. And finally, we do have, or we do need for blue green, a new component here, which is a load balancer.

I'll explain in a second how that works. Yeah, balancer, balancer. And then we switch the traffic. So we go into switching the traffic to this new version. So we switch the traffic here. And of course, keep this old for a couple of minutes just to make sure that if anything happens, we roll back, but then we can finally kill this. And so when you introduce service side rendering in a front end application, the deployment you need will look a lot more like if you're deploying a back end service.

Can you give us a quick high level overview of what we went through today? Sure. So remember, we have a continuous integration, CI, that would be getting our code from source control with certain git flows to the build pipeline. Which will look different depending on the application, but this is how it looks like for a front end JavaScript application. All this will run into something like Jenkins or GitLab or GitHub actions back in the old days, it used to be all bash scripts.

But that's not the case, fortunately. Then it will all build an artifact, either a zip file with your deployable version of the application. And ideally, in the best companies, there will be an artifact repository. This is something you can buy from Azure DevOps or GitLab, where basically like a cloud folder where you push versions of your built application of your deployable version. After that, you can stop, right? We finished the build process and then we can go into deployment.

Now, I did not add it here the word continuous deployment, you know, CICD, continuous integration, continuous deployment, because you can only do continuous deployment if you have a lot of uh automated test coverage and you don't have an intermediate stage. But most companies will take your code, take your artifact, upload it to the environment where it has to run and then either do a restart of the server and redirect the traffic to the new version.

The important thing here is you can do this repeatedly, very quickly, very fast in the case you have a live bug or you have a to roll back really quick. And that's pretty much it in a nutshell the deployment for a small to mid-sized application. If we go into enterprise software, we will have to upgrade things uh a bit more, but I think the also will leave that for a next video. Let us know in the comments if you want barn night to do a follow-up on this video and go a bit deeper, maybe go also into the back end deployment side of things.

By the way, if you are interviewing right now or if you're just curious in finding out what your gaps are to us the senior level, then check out the link to the free tinkle assessment we put together in comments. It's going to take you around 10 minutes and by the end of it, you'll have a complete overview of what your tinker gaps are and how you can go about fixing them. Thank you so much for the nice overview and great drawing skills.

And we will see you folks in the next one.