Jeff Terrell: Okay.
Jeff Terrell: i'm using a headset this time because I finally listened to a recording and realized that the sounds is really kind of awful still so.
Jeff Terrell: apologies if anybody has noticed those quality issues, probably many people have but I hadn't feel free to mention such things to me, but hopefully this headsets gonna work out better good glad this is better.
Jeff Terrell: And yeah so we'll talk about deployment today.
Jeff Terrell: A couple of announcements first remember that the APP lab exists, so if you need help with anything sort of technical about your project that would be a good place to ask.
Jeff Terrell: there's no guarantee that they'll always you know know all of the technologies that you are using etc, but you know, there are some pretty knowledgeable people there.
Jeff Terrell: And that would be a good place to go, for you know if you have questions or it gets stuck or even on deployment issues that'd be a good place to go also remember that, I do have office hours a couple of y'all have taken advantage of that this week so that's great if you get.
Jeff Terrell: Maybe your mentor might say, well, this is kind of a thorny issue, maybe you should talk to the instructor about it, or maybe you go to the APP lab and aren't able to get help for what you need there I am available, so you can schedule this times.
Jeff Terrell: I believe the link is on the syllabus page so.
Jeff Terrell: Also, I realized that tuesday's not the best way to predict grades because Raj doesn't always have all the grading done by then so i'm going to switch to updating grades on Thursdays.
Jeff Terrell: Okay, to set the stage for talking about deployment today, and this, by the way, is one of my favorite lectures to give in this class I really enjoy this one, I want to talk about software and what the nature of software is.
Jeff Terrell: Famous venture capitalist Marc andreessen who has kind of made a fortune betting on software companies over the years.
Jeff Terrell: he's one of the names behind andreessen Horowitz, which is one of the most famous venture capitalist firms in Silicon Valley and.
Jeff Terrell: wrote a Wall Street Journal editorial that made the point necessities phrasing that software is eating the world, it was a memorable way to say it, and I think it gave a lot of people words to describe kind of what they were noticing in various industries.
Jeff Terrell: And the idea is that software, you know if it hasn't already disrupted the industry that you're in it's going to.
Jeff Terrell: And when it disrupts an industry What that means is that, as a company, you have to get good at software in order to stay competitive if you don't, you will get eaten alive by your competition, who have figured out how to use software.
Jeff Terrell: So those who leverage software effectively are out competing those who do not.
Jeff Terrell: And by the way, isn't that Nice that's we are the music makers in this scenario right we know how this works, we can create the software and be the wizards behind.
Jeff Terrell: All of this and and hopefully get compensated well for it so it's kind of Nice.
Jeff Terrell: And it's not just enough to use software it's really about how well do you use software.
Jeff Terrell: And Well, this is not the words that andreessen used but i'm going to say that a fair summary is well approximately means in an agile way so with what kind of agility can you use software that means writing software faster.
Jeff Terrell: That means fixing bugs faster and the software that you've written.
Jeff Terrell: Maybe you need to pivot faster maybe your competitor came out with some new feature, and you don't have that yet so how quickly, can you pivot and add that feature to your offering.
Jeff Terrell: So the better, you can do that kind of stuff with software, the more competitive you'll be and the more likely you'll be able to to win amongst your competitor competitors.
Jeff Terrell: Now, a lot of us have seen this kind of stuff before it's really not that surprising and 2021 it was surprising to some people in 2011 to realize.
Jeff Terrell: How significant and pervasive for software was a lot of people kind of realized that already, and this just gave them words to describe something that i've been seeing.
Jeff Terrell: But.
Jeff Terrell: When you stop and think about what is this statement actually mean try to deconstruct this sentence software is eating the world.
Jeff Terrell: What is software.
Jeff Terrell: What is he talking about when he says software is eating the world.
Jeff Terrell: Think about it for a second if you if you want to hazard a guess feel free but, if not that's fine just think about it for a second what actually is software.
Jeff Terrell: i'm going to say that software.
Jeff Terrell: is just a set of instructions stored on a disk somewhere it's just it's just bits on a disk.
Jeff Terrell: And the important point about this is that software by itself is a nurse doesn't do anything it's just sitting on a desk ready for something to use it, but software by itself doesn't do anything.
Jeff Terrell: Right, these are these are machine instructions that's all.
Jeff Terrell: And so, for software to actually be useful, it has to be animated somehow there has to be some sort of an animating force.
Jeff Terrell: To make the software do something.
Jeff Terrell: So those machine instructions have to be combined with the machine that understands those machine instructions and is able to execute those machine instructions, but without the machine without the animating force software is actually pretty useless just taking up space.
Jeff Terrell: So the word that will use for this animating force is a system which is very much related to the idea of system when we talked about systems in the architecture lecture a couple lectures ago.
Jeff Terrell: Remember, we talked about systems and components, we talked about examples of systems, including things like the plumbing system of a house or the electrical system of a house.
Jeff Terrell: And noticing those two systems those two examples you have an animating force which is effectively a sort of pressure.
Jeff Terrell: pushing the The thing that you need the resource that you need whether its water or electricity to all of the places that you might need it and then it's up to you to like plug in or turn the faucet or whatever to actually use it, but the pressure is providing that.
Jeff Terrell: And I don't know, making it available for you, wherever you need it and you could say that that's the kind of animating force but, of course, right now, we're talking about software systems and so yeah we'll talk about.
Jeff Terrell: we'll talk about systems so system is is essential, a software system so sort of animating force or machine is essential to software providing any value at all.
Jeff Terrell: So perhaps a more precise phrase than what andreessen offered would be software systems are eating the world maybe that's not quite as catchy but.
Jeff Terrell: You know, when you get right down to it, software by itself as an art.
Jeff Terrell: So we're going to talk about the system today.
Jeff Terrell: And in particular we're going to talk about agility of the system.
Jeff Terrell: So this gets back to software is eating the world and, if you want to compete with your peers in your industry it's not just that you need to be agile, with respect to software development.
Jeff Terrell: it's also that you need to be agile, with respect to the systems that you use to animate that software.
Jeff Terrell: You need to not just be agile in software, but agile in systems.
Jeff Terrell: And the core idea of class today is how do you unlock system level agility, how can we create agile systems question.
Jeff Terrell: anime is something I mean by itself software is just bits on a disk and it's not doing anything so something has to come along and actually execute that as instructions so it's got to make it move it's got to make it do stuff.
Jeff Terrell: Tom I see your question but i'm not quite sure what you're asking feel free to add some clarification there.
Jeff Terrell: Okay, so examples of system agility it turns out that you give me a big tech company and it's it's a given that they are doing system level agility.
Jeff Terrell: Maybe it's mere correlation it just so happens that all of them are doing that, but I actually think it's more than that, I think it's causation I think part of the reason why.
Jeff Terrell: Some of these big name companies have become successful is that they have figured out how to be agile with systems.
Jeff Terrell: A key metric for this, if you want to measure it and put a number on it would be the number of production deployments per day.
Jeff Terrell: And here's here's another thought exercise for you how many production deploys per day, do you think some of these big name companies, you know your your fan companies Facebook apple Amazon Google.
Jeff Terrell: How many production employees do you think they do per day, and you can again if if if you want to hazard a guess you can, but at least think about it.
Jeff Terrell: You know it with desktop software.
Jeff Terrell: I have Ms office on my IMAC and i'll occasionally get an update notification, you know, like hey let's update Microsoft word, maybe every other week i'll get some sort of an update and they'll it'll download it and install it for me.
Jeff Terrell: But we're talking about a certain number per day all right here's here's the big reveal Amazon announced it deployed 130,000 times per day.
Jeff Terrell: that's more than once a second.
Jeff Terrell: Like at this rate, they deployed 15 times since I started this slide.
Jeff Terrell: it's crazy right.
Jeff Terrell: Now they have a lot of different services that they're keeping up to date so it's probably deployments across a lot of different different services, but even so that's that's an insane that's a staggering number.
Jeff Terrell: And that was in 2015.
Jeff Terrell: I guarantee it's increased since then, by a substantial margin.
Jeff Terrell: Google has also exceeded 10,000 deploys per day for a while this slide is like two years old and i'm probably well above that at this point.
Jeff Terrell: And there are some side benefits to having this kind of thing happened at the company that you work at.
Jeff Terrell: It turns out, employees tend to be happier.
Jeff Terrell: This is a real thing.
Jeff Terrell: If you imagine how stressful it would be to create one deployment per quarter or even per year, I mean companies used to do this and some still do.
Jeff Terrell: they're getting out competed by the people who figured out how to have system level agility but some companies still do this and it's a nightmare.
Jeff Terrell: Having to wrangle all these different changes and bundle them up together and then you get really nervous and the days leading up to hitting the big deploy button and then things break and you have to be on call, and you have to fix these things as emergencies it's it's a pain.
Jeff Terrell: So it's really nice when you're an employee at a company like this and you just write this code you, you make sure it works and then.
Jeff Terrell: You hit the button whenever you're done, you know five times a day if you get that many things done and off it goes to be deployed, and you don't have to worry about a.
Jeff Terrell: lot nicer scenario for a software engineer.
Jeff Terrell: This idea of system level agility is kind of a key idea behind the phrase devops probably many of you have heard the phrase devops it's become a pretty popular phrase these days.
Jeff Terrell: Some people actually don't really use it correctly, some people think it's just a newer you know trendy way to say like OPS, or it or something like that it's more than that.
Jeff Terrell: devops is about a culture of continuous collaboration between developers and operators Dev and OPS.
Jeff Terrell: So the idea is that you're bringing the developer, and the it person or the infrastructure person or the operator.
Jeff Terrell: onto the same team sort of permanently so that they're collaborating the developer is helping the OPS person.
Jeff Terrell: automate their operations.
Jeff Terrell: Maybe do version control on their operations, and you know there's some things that developers can add to that and and operator is helping the developer.
Jeff Terrell: understand what the operational constraints of the system are in production so it's a really good pairing.
Jeff Terrell: And usually these relatively dysfunctional organizations that only deploy you know, a couple of times a year tend to have like the developer division.
Jeff Terrell: And the it division and if you're a developer you don't know any operators if you're an operator you don't know any developers unless maybe you're in a war room together because something broke generally there's a lot of finger pointing in those kinds of situations to.
Jeff Terrell: So devops is about bringing those two types of people together for collaboration and doing that, on a continuous basis and just a culture of that kind of collaboration if you're interested in this, I actually really enjoy this book The phoenix project.
Jeff Terrell: It came out in I want to say 2014 and it's actually it's a fictional book it's an allegory it's like.
Jeff Terrell: describing a fictional company that's very dysfunctional as far as these things go.
Jeff Terrell: and talking about problems that it got into and kind of painting the picture there and then talking about how they were able to sort of turn the ship around as they introduced some better processes and.
Jeff Terrell: I found it really readable really engaging really fun, so if you're interested in that it's a pretty easy read and can really open your eyes to different ways of doing this.
Jeff Terrell: By the way, i'm.
Jeff Terrell: Understand like if you if you believe me that I know what i'm talking about here with system agility and how important that is for the entire industry for industry after industry, you know software eating the world, and all that.
Jeff Terrell: It would behoove you to know how this stuff works.
Jeff Terrell: To not just be a good software developer, but to also be knowledgeable about how to do system agility how to make those pipelines of of you know, production deployments and things like that this could really distinguish you from your peers, when you land a job in industry somewhere.
Jeff Terrell: Being able to understand the bigger picture and not just the code base in front of you, but the bigger picture of how it's deployed, and what the overall system is and how to improve that system and make it more streamlined and and so on, that can set you apart.
Jeff Terrell: Questions so far about software eating the world the importance of system level agility anything else.
Jeff Terrell: Okay.
Jeff Terrell: let's switch to a survey, I was interested to get some feedback for.
Jeff Terrell: quizzes one and two.
Jeff Terrell: polivy.com slash Jeff terrell.
Jeff Terrell: My goal for the quizzes is that they will.
Jeff Terrell: be easy if you've been paying attention and lecture and that won't require a lot of studying or any studying really so i'm just trying to check to see if i'm kind of in the right ballpark with those.
Jeff Terrell: Thank you for feedback i'll review your your comments later.
Jeff Terrell: Okay back here.
Jeff Terrell: So we've talked about why system level agility happens.
Jeff Terrell: Now I want to talk about how to actually make that happen that's really, what I want to teach you today, and the best articulation that I found of doing this is called the 12 factor APP.
Jeff Terrell: This was kind of a big deal when it came out I don't remember when it came out, it might have been.
Jeff Terrell: Late aughts something if I had to guess.
Jeff Terrell: And this is a lot of the basis for the her roku service or roku is a way to deploy applications like back end applications that I actually really like I like a roku quite a bit and 12 factor APP is encapsulating in kind of.
Jeff Terrell: Discussing the principles that underlie how her roku went about doing it.
Jeff Terrell: OK so again, how do we enable system agility by following a recommendation, so the 12 factor APP which you can find it 12 factor.net one two factor.net.
Jeff Terrell: Let me mention briefly here, who is this primarily useful for.
Jeff Terrell: desktop Apps as I kind of refer to before about you know Microsoft Office updates and things like that usually those are going to get deployed either by sticking an installer package on a website, or I guess in the olden days, maybe a CD Rom or something.
Jeff Terrell: And you'll probably get updates if your APP is decent it'll sort of notify you that there's an update and offer to install it for you, so I i'm not really talking about desktop Apps I don't think desktop Apps apply to any projects in this in this offering a 523 anyway.
Jeff Terrell: But system level agility for desktop Apps don't really make sense.
Jeff Terrell: Mobile Apps also don't it doesn't really make as much sense to talk about system level agility for mobile Apps.
Jeff Terrell: Because the way you deploy a mobile APP is by uploading a compiled package to the APP store right and the system level agility is something that hopefully at apple and Google are handling and doing a good job of but it's not your concern as a developer.
Jeff Terrell: So if you are one of the projects that is intending to build a mobile APP and only a mobile APP then this lecture might not be as useful for you, but I hope that we will serve you in the future, and like I said I think it's an important thing that can really distinguish you as an engineer.
Jeff Terrell: To understand some of these concerns.
Jeff Terrell: So we'll ignore both of those approaches and really just focus on web Apps that need a back end.
Jeff Terrell: Now i'll mentioned, there are, if you want to adopt extra constraints, there are ways that you can have a back end service, rather than having a sort of hosting service or.
Jeff Terrell: I don't know what else to call it, but you know her roku you get to upload whatever kind of back end you want.
Jeff Terrell: I suppose there are some constraints on that as well, but for the most part, whatever kind of back end you want, if you use something like firebase.
Jeff Terrell: firebase has more constraints.
Jeff Terrell: You know you have one choice of database as firebase kind of is the database, I suppose there's like two options, but they're pretty similar.
Jeff Terrell: You have, I think three choices for what language you're going to use to interact with firebase you can either do android ios or if you're doing any sort of web APP you've got to use.
Jeff Terrell: javascript or typescript so I don't think.
Jeff Terrell: i'm not an expert in firebase I could be wrong about this, but I think you're pretty constrained in your choices, you have one API that you can use for firebase.
Jeff Terrell: there's one way to query data there's one way to update data, so if you are willing to take on those constraints and if those constraints work decently well for your project five, this is actually really great firebase will handle all the system level concerns for you.
Jeff Terrell: And all you do is tell it your front end code and you really should tell it some authorization rules, just to so that you can tell who gets to update what kinds of data.
Jeff Terrell: But um but yeah actually recommend firebase if anybody's interested in that, in fact, to the other instructor for COMP 523 Dave starts he emailed me sometime last semester, when he was offering it and he said I don't know what's happening, but.
Jeff Terrell: The students are having a lot more success actually delivering software, at the end of the Semester than they ever have had before, and I said, what do you think's going on, he said I don't know it might be that I recommended that everybody use firebase.
Jeff Terrell: And I said, good to know, so this is kind of my my plug I guess I got to dig into firebase a little bit this past summer and it really is pretty convenient so if you're wondering, you know how am I going to deliver this back end and deploy this back end, that is a good option.
Jeff Terrell: Now.
Jeff Terrell: i'm going to talk about her roku roku is a little bit more involved in firebase but it's also more flexible, so you don't have as many constraints, you can use different kinds of programming languages, for your back end, you can use different kinds of databases.
Jeff Terrell: And there's some really neat things about it that i'm going to get into but.
Jeff Terrell: But if you're using firebase you also might not be sort of the best, most targeted audience here for this, the rest of this lecture but nevertheless I think it's useful content we're going to we're going to go through it.
Jeff Terrell: devin says firebase is the best thing since sliced arrays.
Jeff Terrell: Okay 12 factor APP overview.
Jeff Terrell: So these are as i've said before, these are some principles underlying good practices for system level agility.
Jeff Terrell: There are implications for how your APP runs in production, as well as how you develop your APP locally we'll talk about all this, the key ideas that you're going to have a clean contract with the operating system to enable easy portability of your code to multiple computers.
Jeff Terrell: notice a portability is pretty related concept to agility agility is like being able to move quickly and if something isn't portable it'll be a lot harder to move right so.
Jeff Terrell: Being able to have a clean contract with the underlying system so that you can easily move your your your code to different systems is a an important idea here.
Jeff Terrell: So we're gonna walk through the 12 principles principle one.
Jeff Terrell: One code base many deploys.
Jeff Terrell: code bases just a database of code, this is basically a repository usually stored in get maybe hosted on github or get lab or something like that.
Jeff Terrell: Each deploy is a running instance of that APP that comes from the same code base.
Jeff Terrell: And we'll talk about kind of what instances, and how that gets compiled and everything but.
Jeff Terrell: But you can have many running instances of the APP running in different places, but it's all coming from the same code base this might seem kind of obvious.
Jeff Terrell: And some of these things have definitely become accepted best practices and that's why it's obvious to you at this point is that everybody now does it this way, but it wasn't always the case, nearly as much when this came out.
Jeff Terrell: The obvious deploy would be a production site also called prod.
Jeff Terrell: This is usually you it's more say like be production site there's usually only one prod site, and this is where the generic user out there will access your service, this is the publicly facing service that you provide.
Jeff Terrell: You might also have another deploy, which is a staging site.
Jeff Terrell: And this is where, if you had some features that you want it to be able to review and sort of vets do some quality assurance on before they hit the way they went live and we're available to all users.
Jeff Terrell: You could put them on a staging server and maybe you have that staging server configured to where maybe only people within your company can access it maybe there's another layer of sort of authentication or protection there but it's a way to test things out before they hit the masses.
Jeff Terrell: You also are going to need one Dev deployment per developer calling this a deployment is it a little bit odd it might be better to call it a Dev environment or maybe call any of these environments, but.
Jeff Terrell: I don't know it works, so if you have three developers, you might have four total deployments one production and three, one for each developer.
Jeff Terrell: Or maybe five if you have the staging one.
Jeff Terrell: important aspect of all these deployments is that they should they must be isolated from each other.
Jeff Terrell: If they're not isolated isolated from each other, then what happens is i'm sitting there trying to trying to do some code and get some things done on my development, environment, but.
Jeff Terrell: Maybe, something that some other developer on the team did suddenly affects what i'm doing and I introduced to some bug and i'm like let it and.
Jeff Terrell: I don't think I changed anything related to that and it takes me a long time to figure out what the issue is and it's because my development environments we're not isolated from each other.
Jeff Terrell: So they should all have their own sort of resources and everything only affects.
Jeff Terrell: themselves and nothing else.
Jeff Terrell: But again, that the point of principle number one is that prod and Dev and staging and anything else, that you have they're all going to come from the same code base.
Jeff Terrell: Usually, it is a bad idea to separate repositories for front end and back end I have seen projects that did this in the past and that's what kind of spurs this comment is that.
Jeff Terrell: that's usually a bad idea, usually you want to have front end and back end in the same repo don't split that across repost it's going to make your life more complicated.
Jeff Terrell: There are occasional reasons to do that if you get into microservices and you get into fancy things, maybe, but probably every project here should have the same same Repo for front end back end Max.
Jeff Terrell: Right yeah companies are switching to mana repost Yes, this is a trend that I have noticed as well there's a really neat article if you're interested in this i'm.
Jeff Terrell: Probably about four years old, or so maybe a bit more, it talks about how Google does their source control management and they actually have one mono Repo for.
Jeff Terrell: All of the code that they write, with the only exception of android android open source, and so they split that out, but.
Jeff Terrell: Everything else that they write is in a single repo so imagine gmail Google every Google service that they offer it's all in this one huge repo.
Jeff Terrell: And one of the reasons for that is that they don't have to worry about dependencies everything that they need is right there and it's a huge repo.
Jeff Terrell: And if you imagine 10,000 developers I don't have any they have are all working on this repo simultaneously turns out.
Jeff Terrell: They have to add some pretty fancy processes around version control management and source control management like I don't think they even use get for this.
Jeff Terrell: Just doesn't even work when you're trying when you have like a million commits every day or something ridiculous like that so.
Jeff Terrell: So yeah and they they kind of have all of their processes built on this one mono repo anyway it's it's pretty interesting but um but yeah that is kind of a trend it's bringing a lot of repose together into a mono repo.
Jeff Terrell: If you're curious actually You might ask your mentors what they think about some of these things ask them, you know what do you think about mana repose or what do you think about the 12 factors.
Jeff Terrell: And 12 factor APP and if they if they haven't been around a while they might not know about the 12 factor APP I don't know that was more of a thing that made a splash a few years ago, but.
Jeff Terrell: They might have some fun opinions for your stories about things.
Jeff Terrell: Okay questions about principle one one code base many deploys.
Jeff Terrell: Okay number to explicitly declare and isolate dependencies this is really important for portability of your code across different machines.
Jeff Terrell: The problem that you often run into if you do not do this, is that you have the same code and it runs on one system, but it does not run on another.
Jeff Terrell: And the usual reason, this is the case is because there were implicit dependencies that were installed in one of the systems, but not installed in the other, they were implicit they were they just happened to be installed in one place but.
Jeff Terrell: Maybe you forgot to install them in another place, or maybe they just happen not to be in the other place and because they're implicit it's harder to track them.
Jeff Terrell: So the solution this gets back to the idea of having a clean contract with the operating system or the underlying system first be explicit about your.
Jeff Terrell: Your dependencies you explicitly list all of the dependencies in your APP.
Jeff Terrell: A lot of languages are doing this just fine these days, this is definitely become a best practice and so like in a node js project you're going to have a package json file that's going to include all of your dependencies from mpm.
Jeff Terrell: or in Python you'll have a pip file and there are similar things for pretty much any language.
Jeff Terrell: These dependencies, by the way, are.
Jeff Terrell: These are like library level dependencies like dependencies within the language there's another kind of dependency that will.
Jeff Terrell: i'll talk about just a second but.
Jeff Terrell: um but yeah having all your dependencies explicitly listed has become a pretty accepted, you know way of doing things that it's kind of hard not to do it, these days, honestly.
Jeff Terrell: The thing that I think is not really part of the state of the art, yet which I think should be, I think it would be better if it were is to isolate your APP so that only your list of dependencies are accessible.
Jeff Terrell: Most most ways that you can build an APP most languages that you can use.
Jeff Terrell: there's going to be kind of a chain of different places that your system is going to look for different dependencies and if you forgot to put them in your package json.
Jeff Terrell: And they happen to be installed more globally, on your system, then it'll still be able to pick it up and run and that's specifically what this is talking about not doing this is saying if it's not explicitly listed, it should not be accessible period.
Jeff Terrell: Most languages in my experience, I have not really caught on to this idea, yet.
Jeff Terrell: So yeah most most common types of dependencies would be like package level dependencies or project level dependencies and like I said most.
Jeff Terrell: languages are good at doing that these days, but something to be aware of is that there might be other kinds of dependencies as well, there might be system level dependencies.
Jeff Terrell: For example, curl is a command that you can use to send http requests and see the responses just a command line tool, maybe you have that setup in your testing to run tests against your API.
Jeff Terrell: or Pandora Pandora is something that converts.
Jeff Terrell: content from one markup format to another, and I use it to I write all of my content for the website for this course and mark down, and I use Pandora to convert it to html so that I can deploy it to a static static server.
Jeff Terrell: image magic would be another one if your back end service needs to do anything related to image manipulation and resizing and things like that, then you probably are going to have a system level dependency on image magic.
Jeff Terrell: And the idea here is that you want to explicitly declare not just package dependencies but also the system dependencies for principle to.
Jeff Terrell: So one approach would be to what's called a vendor those system dependencies into your repo maybe you have the source code right there and in a directory in your repository and your build instructions include instructions for building that that application or that library.
Jeff Terrell: Or maybe use docker docker has become a pretty significant thing happening in the in the development world.
Jeff Terrell: And docker will let you be explicit not just about your package dependencies and tech docker doesn't care as much about your package dependencies but docker can capture your system dependencies in a systematic and explicit way.
Jeff Terrell: So that's one of the reasons docker has really caught on.
Jeff Terrell: there's a couple layers sort of more extracted from docker as well, like docker compose and Cooper 90s piece of things i'll take some time to learn.
Jeff Terrell: In some cases, that can slow you down and make it harder to deliver value to your client in the course of a semester, but they're they're worth knowing about anyway, even if you don't dive deep and understand how they work.
Jeff Terrell: Questions about principle to.
Jeff Terrell: Okay.
Jeff Terrell: principal three a store config and the environment, so the astute observer, you might have been wondering.
Jeff Terrell: If we have one code base and many deploys, how do we isolate the by environments.
Jeff Terrell: How do we have the production deploy accessing a different database and the development deploys.
Jeff Terrell: If they're all running from the exact same code base.
Jeff Terrell: So how can anything, be different if you have everything in the same code base, and the reason the the answer to that is that there's information that exists outside of the repo outside of the code base.
Jeff Terrell: and information is called the environment or the config.
Jeff Terrell: And that is a separate thing from the code base.
Jeff Terrell: Now, from an operating system standpoint this relies on the fact that.
Jeff Terrell: I think all operating systems, including windows actually have a notion of an environment for a process and the environment is you can think of it as a hash map with string keys and string values but it's basically a set of like name value pairs.
Jeff Terrell: If you're in a unix type operating system, you can type the command end to see the current environment of your shell.
Jeff Terrell: But examples of environment variables, would be a port.
Jeff Terrell: Usually in all caps you don't have to be.
Jeff Terrell: or a database URL so you should be things that.
Jeff Terrell: you're basically your operating system can provide to your process.
Jeff Terrell: And so the idea here is that you will be running code from the same code base, but your environment will differ your config, in other words will differ from one deploy to the next, and that is how deploys can be isolated and how they can have different things happening.
Jeff Terrell: The key idea here is that anything that's able to vary between deploys.
Jeff Terrell: Is what you should store in the config.
Jeff Terrell: So, if you think about maybe you want different databases between Devon prod.
Jeff Terrell: Development environments in production environments, then that's a clue that you're going to need to have some config related to where the database lives.
Jeff Terrell: And really you only want those kinds of things in the config you want your config to be as small as possible.
Jeff Terrell: I know there are some places, some some frameworks will have different kinds of config files in the in the way the framework expects to run, so I know like rails will say routes.rb it's kind of like a config file for what your routes are for your web APP.
Jeff Terrell: that's not varying between deploys such as part of your APP even though you might consider IT configuration of a sort that's not the kind of config that we're talking about here we're talking about the stuff that can vary between deploys.
Jeff Terrell: And how do we keep that stuff out of the code base so, for example, if you have a csv file at the root of your project, which is a common way to do it it's just called in.
Jeff Terrell: Then you can ECHO.
Jeff Terrell: This string and append it this isn't a basket pedal Shell, by the way, appended to the get ignore file the docket ignore file.
Jeff Terrell: This is telling get I want you to ignore the end file at the root of the repo.
Jeff Terrell: And that way I can have one, you can have one other developers on the project can have one all of our interview files can differ.
Jeff Terrell: And we won't ever accidentally check those files in to the repo so it won't be part of the code base it'll be apart from the code base and we can use it in our config.
Jeff Terrell: So again, just to hammer the idea home config varies across deploys code does not.
Jeff Terrell: A code is varying all the time because we're adding features so code varies across features.
Jeff Terrell: code does not vary across deploys config varies across deploys and does not vary across features.
Jeff Terrell: Questions about number three.
Jeff Terrell: Okay.
Jeff Terrell: Number four treat backing services as attached resources.
Jeff Terrell: Basically, this means that any sort of service that you need such as a database or an email sending service or anything else, this needs to be accessible through a URL.
Jeff Terrell: And the particular URL to use should be part of your config because that needs to be able to vary between different environments.
Jeff Terrell: whatever kind of resource that you're using you're going to want to have a different one, probably for all of your different environments so so you want that to be part of your config.
Jeff Terrell: If you need to at that point it's really easy, this is getting back to system level agility this other component that i'm depending on this attached resource.
Jeff Terrell: is part of my system it's part of an overall system right and depending on it i'm using it for different things.
Jeff Terrell: But to have a God that I need to be able to quickly sort of tear that down and spin up a new one, so, for example, let's say that i'm.
Jeff Terrell: i've got a small database and i'm really starting to hit the limits of what that database can do.
Jeff Terrell: So I spin up another database I sort of migrate all the data over and once that migration has done in the end the bigger database is ready.
Jeff Terrell: Then I point my APP instead of at the small database, I pointed to the bigger database.
Jeff Terrell: And then I can kill the small database that's a pretty easy sort of transition to make at that point, because I have treated these different resources as they're just attached I just refer to them by URL.
Jeff Terrell: that's part of my config.
Jeff Terrell: Another thing you could do is, and this does happen, sometimes you realize that.
Jeff Terrell: Maybe there's a problem in the production data we shipped some bad code and we accidentally corrupted the data somehow.
Jeff Terrell: And I can fix it, if I can get into the production database.
Jeff Terrell: And one way to do that would be in my development environment i'm just going to change my local configuration.
Jeff Terrell: Instead of pointing to my own personal database instance i'm going to point it to the production database instance that way i'm in a familiar environment, on my own machine but i'm able to access that production data and update things there as needed.
Jeff Terrell: And that's enabled by treating backend services as attached resources just referring to them by URL.
Jeff Terrell: Generally speaking, you should not be hard coding URLs in your code right because they might vary between deploys.
Jeff Terrell: And you probably do not want to use a database like sql light or H2, and the reason for that is because, how are you going to switch that over to a new database, if you need to it's I mean you can but it's going to be harder to do than if you just refer to it by URL.
Jeff Terrell: Also sq light and H2 are going to make def prod parody harder which we're going to talk about in a minute.
Jeff Terrell: So here's the diagram that the 12 factor website uses for backing services, the ideas.
Jeff Terrell: You have your production deploy and it's referring to all of these services by URL but they sort of exist, apart from the production deploy itself, so I don't know if you can see that, but like each one of these arrows is labeled with a URL.
Jeff Terrell: Something else to know about your else, by the way, I don't know if you know this URLs can contain usernames and passwords in them.
Jeff Terrell: And so, of course, it would be bad practice to have a.
Jeff Terrell: Production database that didn't have any password protection on it.
Jeff Terrell: But that's okay that doesn't hinder you from being able to use a single URL to be able to access that even with authentication because you can say.
Jeff Terrell: You know sql colon slash slash user colon password at host name and then, whatever else you need.
Jeff Terrell: URL can contain the username and password.
Jeff Terrell: question about principle for.
Jeff Terrell: Okay.
Jeff Terrell: number five strictly separate build and run phases.
Jeff Terrell: There are three stages or phases of transforming a code base into a deploy this is typically going to happen, a lot more without like outside of the development environments.
Jeff Terrell: But the three phases would be first to build this is effectively a compilation step you're taking your code and you're converting it into something that can be run, maybe it's machine code or something.
Jeff Terrell: some kind of an executable bundle.
Jeff Terrell: that's the build phase number two is the release phase you combine the builds that you created with a config particular sort of snapshot of what your config value should be.
Jeff Terrell: And that creates a release.
Jeff Terrell: And then step three is to run that release to animate it.
Jeff Terrell: So diagram on the 12 factor APP site.
Jeff Terrell: shows this you've got your code and when you create a build in the build phase you transform that build into an executable bundle or sorry transform that Code into an executable bundle.
Jeff Terrell: you combine that bundle with the config a snapshot of what the current values of the configure and this creates or, at least, which can be run.
Jeff Terrell: If.
Jeff Terrell: i'm going to skip around a little bit releases our version, maybe you start with version one and keep going eventually you get to version whatever version 123.
Jeff Terrell: And releases are immutable once you create a release, you will never change it, you never get into a release and start changing things within that release if you need to change the config.
Jeff Terrell: Then you take your latest build and combine it with the updated config and you create a new release that releases also immutable.
Jeff Terrell: If you need to change the code well, you have to redo the build phase, and then you combine that with the current config and release it.
Jeff Terrell: Okay, but each release is immutable one of the neat things about that is that if you make a mistake and you ship code that has a bug in it, maybe it even crashes your whole service.
Jeff Terrell: Rather than try to hurry and fix whatever it is, before too many people notice or too many people are affected, you can just roll back.
Jeff Terrell: If version 123 was bad just roll back to version 122 everything's fine and then you can take your time to fix whatever that bug was in version 124.
Jeff Terrell: The build happens in the foreground synchronously meaning it's it's going to be going and nothing else, is going to happen until the build is done.
Jeff Terrell: You can see the output of the build.
Jeff Terrell: And so it's important to make errors happen there if possible.
Jeff Terrell: That way you're not woken up in the middle of the night when somebody notices a build at runtime.
Jeff Terrell: Because it wasn't caught at build time, and this is effectively the argument, this is an old argument that goes back to static versus dynamic languages, if you take programming languages we might discuss that more but.
Jeff Terrell: static languages would say we want to discover as many bugs as we possibly can, at compile time which is effectively your build phase here and that way we won't be noticing them at runtime we won't be surprised by them later and users won't be affected.
Jeff Terrell: This is one of the reasons, people would switch from javascript typescript typescript is going to detect type errors at compile time rather than at runtime.
Jeff Terrell: I think there are some good arguments for dynamic languages, too, but.
Jeff Terrell: that's kind of out of scope of this discussion.
Jeff Terrell: And one just sort of pro tip don't be a cowboy this is kind of a term that derogatory derogatory term that people use for people who had production systems sort of live or some sort of bug and they go fix it in production.
Jeff Terrell: Usually that ends up being counterproductive in the long run, like Okay, what did you do.
Jeff Terrell: You don't remember okay great, so now we have to figure out what you did, and hopefully we'll get it right and it can be a mess.
Jeff Terrell: Okay questions about number five.
Jeff Terrell: build phase release phase front face yeah.
Jeff Terrell: To do what in production.
Jeff Terrell: test and production.
Jeff Terrell: yeah no, I think that can be good, I think one of the things you can do is stress test your servers.
Jeff Terrell: And test to make sure everything's up and running correctly or how much load can they can they bear yeah don't testing and production said I find thing to do.
Jeff Terrell: Sorry.
Jeff Terrell: Well yeah yes, I mean he need to you need to be find as many bugs, as you can before you ship it to users yeah yeah I would definitely say he should do that.
Jeff Terrell: yep if you're if you're only testing and production now have your problem.
Jeff Terrell: But now, there are certain kinds of tests that do make sense for production systems.
Jeff Terrell: All right number six execute the APP is one of more stateless processes.
Jeff Terrell: The APP is going to get rebooted a roku will actually reboot your server I think every 24 hours at least.
Jeff Terrell: And so you don't want to be accumulating information that's important in memory, if you have stuff that can be thrown away like you just have stuff that's cashed in memory that's fine so like you can never store anything in memory, but it's like you don't want to be storing state.
Jeff Terrell: Important state in your memory of your process, because that process is going to die and get replaced.
Jeff Terrell: So don't do like inter process communication between different processes, because usually there needs to be some state to track back where the communication is that.
Jeff Terrell: In it it's just that hinders agility.
Jeff Terrell: There used to be a pattern called sticky sessions it's not so much not so popular these days, but if you had multiple web servers the servers could store.
Jeff Terrell: session information for clients in memory.
Jeff Terrell: And the load balancer at the front, they sort of decided which server got an incoming request it would keep track and say this client always goes to this server.
Jeff Terrell: And so, all the communications from that client always went to the same server and so that server storing stuff in memory about the session, you know you could make it work.
Jeff Terrell: that's called sticky sessions, but that's not that's a bad idea here sticky sessions having sessions in memory and things like that would be an Anti pattern to Principle number six.
Jeff Terrell: Think about you know if you have four servers and you're realizing that's not really enough.
Jeff Terrell: How are you going to transition to have five servers becomes a much more complicated proposition at that point, because you got to think about.
Jeff Terrell: Splitting a piece of estate out of each of the four servers and bringing that over to server number five all while requests are still in coming and.
Jeff Terrell: becomes a lot more difficult, of a problem much better just to have stateless processes, whatever state, you need should be either in your code base to start exactly state in your config or in your database, or some sort of external service.
Jeff Terrell: Some of these are not as interesting to talk about at least for the context of this class i'll go through them a little bit more quickly number seven export services by a port binding.
Jeff Terrell: This is basically saying that you should only have a single front door.
Jeff Terrell: And that front door should be the same, regardless of what kind of service that you're deploying.
Jeff Terrell: The system will tell you what port to bind to, and it will make sure that any requests coming for your service go to that port now you have to do is listen on that port and respond on that port.
Jeff Terrell: number eight scale out via the process model.
Jeff Terrell: I don't even think this is worth talking about.
Jeff Terrell: i'm going to skip that one maximize robustness with fast startup and graceful shutdown so, in other words, you know your build phase can be slow to compile everything into an executable bundle but your run phase, this is going to happen.
Jeff Terrell: When you're not looking it's going to happen in the background it's gonna happen every night.
Jeff Terrell: And you should be able to pretty quickly shut down gracefully shut down the old system and spin up a new one.
Jeff Terrell: All right, this one is actually pretty important number 10 keep development and production as similar as possible aka Dev prod parody.
Jeff Terrell: So we have a similar problem that I talked about number two when I was talking about dependencies.
Jeff Terrell: The APP works fine locally, but it fails in production.
Jeff Terrell: This is absolutely something you want to avoid these are not fun problems to diagnose and troubleshoot.
Jeff Terrell: You don't want to have to go dig around in the guts of the production system to understand how is this different than what I have which one of these differences is important.
Jeff Terrell: i'm pretty savvy with systems and Linux and stuff like that, and even I don't like doing this it's not it's not fun.
Jeff Terrell: The cause is usually some difference between your production, environment and your local one.
Jeff Terrell: And the solution is to keep Devon prod as similar as possible, this principle is called Dev prod parody, this is a term that you will probably encounter and industry.
Jeff Terrell: To take a bit of a step back and talk about philosophy there's a common theme here to a lot of these things that I think is interesting and worth noting.
Jeff Terrell: You want to reduce the gaps between Devon prod so there's different kinds of gaps.
Jeff Terrell: If you're one of these companies that hasn't really figured out agility and devops and things like that you might have a gap between when you write the code and when it finally hits production.
Jeff Terrell: And this can be challenging because maybe there was some problem in it, or maybe there wasn't any just need to extend it in some way but man it's been months since you wrote that code.
Jeff Terrell: You know you don't remember what that what that was, and if you could see even the same day you hit the button to deploy and you see.
Jeff Terrell: Even the same you know few minutes few minutes later, you figure out are there areas coming in from this or not, you have all that context in your head you've reduced the time gap and so it's a lot easier to figure out what's going on.
Jeff Terrell: You want to reduce the personnel gap.
Jeff Terrell: Where does write code and asked people to play it you want to have those people all working together and being able to quickly understand each other's perspectives.
Jeff Terrell: and reduce the tools gap, so this one that's what this one is really about you don't have different tools existing in Dev versus in prod.
Jeff Terrell: Right, this is the reason why we keep code and config separate.
Jeff Terrell: we're trying to minimize the amount of difference that can happen between Devon prod and we do that through the config when you have to be really careful about.
Jeff Terrell: adding a config setting a config value.
Jeff Terrell: Then you tend to think about Do I really need this or not, and if you don't need it, you don't add it, and what that means is that effectively there's a little bit of resistance to making data in prod different.
Jeff Terrell: Okay treat logs as event streams Basically, this is just saying.
Jeff Terrell: print messages on standard out, and this will be easy for development, because you can just see the standard output stream of your process and in production, you just trust that the system is actually going to like timestamp your messages and make them available.
Jeff Terrell: And then run admin management tasks is one of processes, the idea here is that you still are using the same code base the same config.
Jeff Terrell: As the service that you actually are deploying but for when I processes like when you need to migrate the schema of a database.
Jeff Terrell: you're going to be starting from the same release but you're going to have a different animated command, you know, instead of saying mpm start you're going to say in PM run migrate or something like that.
Jeff Terrell: Okay, so the key goal here of the 12 factor APP just to summarize is agility of systems.
Jeff Terrell: Which is one way that it's just table stakes to be in software, these days, somebody in your company has to be doing this.
Jeff Terrell: or using some service that does a good job at it otherwise your competition is going to eat you so it's pretty pretty important part of modern software development.
Jeff Terrell: Key takeaways for you as builders of applications is extract the thing that varies between deploys as config like port and database URL keep the config out of the code base you ignored in your repo and use the same tools locally and in production as much as possible.
Jeff Terrell: Questions about the 12 factor APP, how do you enable system agility.
Jeff Terrell: Okay.
Jeff Terrell: i'm going to switch to a DEMO I think I have enough time to get through this i'm going to actually use her roku to show you i'm just going to kind of start to finish deploy a little simple back end that I created.
Jeff Terrell: i've mentioned to roku a few times a roku and bodies to 12 factors, in fact, the 12 factors, written by people who founded her roku.
Jeff Terrell: And it's not the only place to deploy your code, but I think it's actually a really good choice.
Jeff Terrell: Especially compared to something like Amazon web services or as your or Google.
Jeff Terrell: Google cloud it's a lot simpler to use, and I mean I use those other services, and there are times when I need it, but.
Jeff Terrell: If it's a pretty simple web APP then her roku is kind of a go to choice for me, as well as firebase for different things.
Jeff Terrell: We talked about how important it is in your APP to optimize as much as possible the user experience of your APP and to create a prototype that.
Jeff Terrell: captures good or that exhibits good user experience or roku is tagline is optimized for developer experience so they know that their users are developers and, in my opinion they do a good job of actually having a good developer experience for using their their service.
Jeff Terrell: You can get away with doing a lot of stuff for free, on her roku and it's not one of these free tears that expires in a year and then you have to start paying it's free for good.
Jeff Terrell: The downside, that the limitation that you hit first of all on a free tier is that your server is going to be hibernated after 30 minutes of inactivity.
Jeff Terrell: And that doesn't mean it's an available that just means next time that request comes in it's going to take it, maybe 30 seconds to spin up a new.
Jeff Terrell: server and serve that requests so it's kind of slow, especially if it hasn't been used in a while and and you can start to feel that but for just trying something out and getting it working, you can get a lot done for free.
Jeff Terrell: There are a lot of different build packs to create builds for common approaches, so if you have a standard, you know node js APP or you have a standard flask APP or django APP or whatever.
Jeff Terrell: Their build packs for all of these things that can believe in her roku will like detect the presence of certain files in your repo and say oh this looks like a flask APP okay and it'll use the flask build Pack for it.
Jeff Terrell: There are a lot of add ons.
Jeff Terrell: and
Jeff Terrell: So a lot of data stores, for example, like these are always in a random order.
Jeff Terrell: mongodb roku postgres that's when I use a fair bit.
Jeff Terrell: rattus.
Jeff Terrell: postgres, by the way, some of these add ons also have free tiers and postgres is one of them, the limitation here is that you can you can only have a 10,000 rows, but if you can keep under that you can have a free web APP including database.
Jeff Terrell: You can monitor your APP make sure they're staying up.
Jeff Terrell: do things with your logs you can send email, these are all just add ons that you can add and these remember attached resources, all of these are available by URL.
Jeff Terrell: So when you provision one of these add ons it'll.
Jeff Terrell: give you a new config value for that URL of that resource.
Jeff Terrell: here's something you might not a thought of if an exception occurs on your back end.
Jeff Terrell: Will you ever know it.
Jeff Terrell: Are you capturing that are you are you sending that somewhere if you're not you might consider a.
Jeff Terrell: An exception service i've used a couple of years before I think i've used roll bar and honey badger maybe century as well.
Jeff Terrell: But the idea is, these are the top level catch, for whatever exceptions might occur in your APP and if it gets all the way there then.
Jeff Terrell: The exception service is going to send it up to the website, like the century website, or whatever send you an email notification and say hey there is an exception in production, you know it happened 20 times in the last hour or whatever.
Jeff Terrell: So yeah there's some there's some cool stuff here messaging and queuing.
Jeff Terrell: User management there's one if you don't want to be in the business of creating usernames and passwords in your database and handling authentication yourself.
Jeff Terrell: You can just use the service for that I think it was actually really great service for this and I has a free tier as well it'll even let you login through Google, or you know these third party things.
Jeff Terrell: So anyway yeah there's a lot of add ons here.
Jeff Terrell: So i'm going to demonstrate how to create a.
Jeff Terrell: How to deploy my back end to production.
Jeff Terrell: With a simple little back end.
Jeff Terrell: here.
Jeff Terrell: This is a public repo if you wanted to you could actually follow, along with this or do it on your own time.
Jeff Terrell: But.
Jeff Terrell: I guess you'd have to fork it into your own github account hurricane last I checked only integrates with github not get lab so that's something to be aware of.
Jeff Terrell: But.
Jeff Terrell: yeah let me do this alright so i'm going to go to her roku.com.
Jeff Terrell: make this a bit bigger.
Jeff Terrell: i'm going to create a new APP.
Jeff Terrell: Can dial it back row see this it's OK OK.
Jeff Terrell: Say COP 523 back and DEMO.
Jeff Terrell: Is the name of my APP i'm going to create it.
Jeff Terrell: And i'm going to actually connect to get hub for this.
Jeff Terrell: So I have already connected my roku account with my github account so.
Jeff Terrell: Shared canvas backend is the repo I want to connect with.
Jeff Terrell: And what this is going to let me do is have automatic deploys This is also called continuous deployment or CD have a CD pipeline, this is really nice.
Jeff Terrell: In fact, I have ci enabled for this repo see is continuous integration, I might have a chance to talk about that more later on.
Jeff Terrell: But the idea is that I have a service that is connected to my repo that anytime the repo sees new commits it will test those has a server that will test them.
Jeff Terrell: And I can tell a roku wait for all the tests pass before you deploy, in other words, if I push a commit up that doesn't pass all the tests do not deploy that one.
Jeff Terrell: All right, i'm only going to play commits that hit master i'm not going to deploy any other commits to this APP.
Jeff Terrell: i'm going to enable automatic deploys so now.
Jeff Terrell: Soon, as I push to commit to master it's going to get tested.
Jeff Terrell: And if the test pass is going to be automatically deployed, and that is.
Jeff Terrell: I don't have to worry about it just kind of is happening in the background, this is how companies get 230,000 you know production deploys per day is they, they have these kinds of pipelines that are set up to just automatically run they don't have to worry about.
Jeff Terrell: i'm also going to manually deploy.
Jeff Terrell: Once this first deploy is going to be manually, and this is my.
Jeff Terrell: This is my build face remember, we had the build phase, which is converting this kind of compiling source code into an executable bundle.
Jeff Terrell: or roku I didn't tell anything about what kind of APP it was, but it was able to detect that this is a closure APP find the closure build Pack and use that to actually create a build from the source code.
Jeff Terrell: And we're at version three already that's interesting I don't know why we skipped one into, but we did.
Jeff Terrell: So now we we can view the APP Peter with this button down here or up top there's an open APP.
Jeff Terrell: And this looks kind of broken, but this is actually what the APP is supposed to do it's just serving an image and the idea is that this is a shared canvas that anybody can draw on this draw rectangles.
Jeff Terrell: And let me actually draw one.
Jeff Terrell: See sure.
Jeff Terrell: Back in DEMO.
Jeff Terrell: Okay, so I drew a little red rectangle there, and if other people wanted to hit this back end as well, you probably won't know the right way to do it, but, but if you did you could draw on this as well, and we could all see the shared canvas so simple little back end.
Jeff Terrell: rookie deploy that for us.
Jeff Terrell: Now this gets a little bit more interesting because I want to also.
Jeff Terrell: make a pipeline and pipeline is going to enable me to create review Apps and i'll show you what that is.
Jeff Terrell: So i'm going to create a new pipeline.
Jeff Terrell: And then the APP that I created is going to be the production stage of that pipeline.
Jeff Terrell: This is where I can have staging as a separate APP second deploy to staging and I could promote staging Apps to become production Apps.
Jeff Terrell: But I also can enable review Apps, and this is a really neat feature of her roku it comes from.
Jeff Terrell: The 12 factors.
Jeff Terrell: I think, is only possible because of the 12 factors.
Jeff Terrell: So i'm going to enable review Apps.
Jeff Terrell: Create new review Apps for new pull requests automatically.
Jeff Terrell: And this choice to review Apps automatically.
Jeff Terrell: So now what's going to happen is every time anybody creates a pull request for this repo or roku is going to notice hey there's a new pull request and it's going to automatically deploy the code that's in the pull request as a review APP.
Jeff Terrell: So let me go ahead and create.
Jeff Terrell: A pull request.
Jeff Terrell: I have clear canvas is one commit ahead of.
Jeff Terrell: master so.
Jeff Terrell: i'm going to create a new pull request here.
Jeff Terrell: This is just adding a new endpoint to clear the canvas.
Jeff Terrell: And so now there's a there's a pull request there's one open pull request and.
Jeff Terrell: notice that.
Jeff Terrell: Her roku found that pull request already noticed and it's already building.
Jeff Terrell: The code in that pull request so have you ever done pull requests and maybe done for code reviews and things like that and.
Jeff Terrell: it's nice to be able to check through and read through the code and say does this look right but wouldn't it be a lot better if you could actually see the result of that code.
Jeff Terrell: So I hope you appreciate this is a really nice feature.
Jeff Terrell: So now, I can say you know I could.
Jeff Terrell: let's see open APP.
Jeff Terrell: I could go on my pull request.
Jeff Terrell: And I mean it's already here it tells me.
Jeff Terrell: This pull request is deployed at this place, but if I wanted to I could add a comment and say check out the the code in action here.
Jeff Terrell: This is a production like environment it's not the production environment but it's in every way, except the config exactly like a production environment, so this is a real good way to get confidence about what you're actually going to be deploying when it hits production.
Jeff Terrell: do some quality assurance on it, make sure that it really works, make sure there aren't any bugs.
Jeff Terrell: And that can be part of the code review and the poor poor quest process.
Jeff Terrell: um.
Jeff Terrell: Let me see here one other thing i'll show you is.
Jeff Terrell: That.
Jeff Terrell: This is, this is a subtlety.
Jeff Terrell: Her roku has a way of serving your APP for a development, environment and that's her roku local.
Jeff Terrell: And so, this concert, so it looks like i'm at local host 5000.
Jeff Terrell: So here's my development, environment and I have the ability to make changes locally, that only I see, and I can see the results of those changes here in this in this view.
Jeff Terrell: Right so it's another environment that's pretty important part of your development is that you can make those changes locally and test it out just where you only you can see, and get things working before you actually commit and push your your code up and maybe make a pull request.
Jeff Terrell: One subtlety about this that I thought was worth mentioning, since we have a little bit of time is.
Jeff Terrell: This is a less convenient.
Jeff Terrell: environment less convenient setup for me, then, the one that I would normally do in this repo which is line run and the reason for that is that I have to do the compilation myself.
Jeff Terrell: If i'm going to.
Jeff Terrell: To do her roku local.
Jeff Terrell: Her roku local is going to be executing the command and the proc file Java, whatever whatever.
Jeff Terrell: And that relies on this jar having been created which, by default, I don't have to create like when i'm just running this locally.
Jeff Terrell: I can say line run and start my server no problem and it'll pick up, whatever the current values in the source code is and start my server.
Jeff Terrell: it's kind of annoying to have to.
Jeff Terrell: manually compile the Code into an uber jar so that I can run a roku local so I don't actually tend to run a roku local.
Jeff Terrell: And in that way i'm violating deaf prosperity right there's a way that I could have a development environment that is more faithful to what's actually happening in production and i'm choosing not to do it.
Jeff Terrell: So oh yeah so now.
Jeff Terrell: Now her roku local will work.
Jeff Terrell: Whereas before if the uber jar isn't there a roku local will not work.
Jeff Terrell: So yeah i'm choosing to violate that principle i'm doing that on purpose, because it's a little bit more convenient not to do a development environment that way, but I also feel like I understand what's happening here well enough that I.
Jeff Terrell: i've accounted for that difference between Devon prod and that's not going to be the source of any errors for me.
Jeff Terrell: Anyway, the point here is that you might run into a similar sort of situation in your development environments where it does make sense to violate def prod parody a little bit.
Jeff Terrell: But just take that into account, especially if you're noticing any differences between Devon prod This is where review Apps can be really helpful because that is a more like production like environment.
Jeff Terrell: And, as with all of these rules, any guidelines there they're probably you can find a reason to violate those guidelines in certain circumstances so there's no laws here there's only recommendations.
Jeff Terrell: Okay last thing I want to do is just make sure that everything else yeah okay is takeaway questions so when you're finished with that you can go and I hope you'll have a good weekend.