 Hello again everyone here locally. My name is Jacob McElroy. I'm a developer at Octeto and the title of my talk is with preview environments everyone is invited to the party. And that's an interesting title to try and get accepted here but what it means is by introducing preview environments to your review process you're able to integrate a more diverse set of roles and include as many people as possible in your review process so that you ultimately have a better product and a better team right? So same with parties the more people you invite usually as long as they're the right people the better the party right? So to accomplish this first I'm going to define preview environments I'm going to talk about what I mean when I say preview environments maybe you've never heard of it maybe you have it's one of those things that's probably defined differently depending on how it's implemented and how you've used it in the past but we'll define what I'm talking about when I mention that and that'll shape sort of what benefits you receive. Then we will compare the review process traditional review process and that with the preview environment we'll compare and contrast and just review that so that we know sort of where we sit there and then I'll talk about the team benefits and this is where I think is the most valuable here there's we could talk about how it's implemented but but how it benefits the team I think is probably the most important aspect because it's the why so let's talk about what a preview environment is. We are defining today for the context of this talk we're defining a preview environment as a full deployment of your application that is deployed in conjunction with the pull request you open up a pull request and then you have a preview environment so it is deployed from the branch that is under review at least at least the code maybe all the code and the automation to deploy that code is all in the same branch but the point is is that the preview environment is effectively using the code that that you're putting under pull request that you want to have reviewed and when the review is complete it all all the resources are cleaned up so it's an ephemeral environment that is specific for the review process it's all it's it's not it's not a staging and the reason that's important is because you think about these ephemeral environments or something like that you may think of a staging environment well it's a little bit different than the typical staging environment which is after emerge right this is before this is your development branch okay so it's very much a development thing and we have a snippet here of a sort of something fulfilling all of that we have a github bot that is said hey your preview your ephemeral preview environment is deployed and and here's how you access it right there and it's a snippet if you use github's code review process you may notice that as a comment and that's what that is so it appears there so that's that's what a preview environment is that's what we're defining it as and since you know we're here at kubecon um i feel like i have to mention that this is one of those things that is really not necessarily made possible but made better made easy and made the possibility of preview environments being more ubiquitous between teams is made possible because of the groundwork laid down by kubernetes cloud development in general you can go from from that's bit bucket logo you can go from bit bucket github git labs with kubernetes to a preview environment and get that all connected up because of all the tools that we're learning about and talking about uh this week right so that's that's amazing and that's how this sort of fits into the greater kubecon world so we've defined it we talked about how it fits well with kubernetes and so that we probably all here have the possibility of doing preview environments so let's compare the review process both with and without preview environments so the traditional code review process is focused on a code diff it it's for developers right a developer typically writes the code creates the pr and is going through a developer focused review process and i don't think that should change i think that's great it it focuses on making sure that the code is appropriately designed for the system that it lives in it's if you have style guidelines you're checking that those match so that everyone sort of code is somewhat coherent coherent and looks together that's very important we're looking for overly complex code and to see if we can simplify it or if it may be prone to bugs now or in the future and the two other things that i would mention that i think is sort of a gray area between it may be better with the preview environment than it is just with the code diff is that the code provides behavior that functions as intended and that there are tests that validate that expected behavior right and that is that is a whole there's a whole world of complication and and expectation there but it's really hard i think most people would agree it's really hard to intuit or know and understand the behavior of your function feature just by reading a code diff right um you may be able to know how a loop may execute and that those types of behavior but the product it's going to be very difficult so that's where yeah you can get some of that from a traditional code review but i think a preview environment based code review is gonna gonna help gonna help so when you're using a preview environment you have a readily available hands-on environment so readily available i think that's important because there are many times in the past before i used preview environments that were automatically deployed where i would pull down a teammate's branch do a deploy myself deploy it locally or remotely whatever was available to me and i and i would do that and i would do the review process there do sort of the preview environment review process i'll take talk about there but i had to there was there were hurdles i had to opt into doing that i had to be able to do a deploy which in some products is not easy some you know we've talked about there's been other talks here where they talk about how some people can do deploy some people can't you know so you have to be able to do that you have access so readily available i think is is super appropriate here um it just happens with preview environments it gets deployed and then you decide if you want to use it or not right and with kubernetes and all that that's cheaper that's easier so you decide if you want to use it or not but it's already there you don't have to decide i want to spend it up i want to take the time to check out the branch everything it just happens and that's great because we all want to do less work and we just want to reduce friction along this whole process right um often preview environments focus on visual changes visual and i'm talking about visual changes to the application so this is where we pull in some of the diverse role set right um how does it affect the ui if you have a ui component how does it affect the log output are your logs noisy because you that's another visual component i think sometimes is that you have to trace logs and and go through all that how does it affect um if you're using automated documentation how does that documentation get pulled out how does it affect so many things uh the preview environment review focuses on functionality right you care about the functional aspect it's not an an automated functional test or anything like that but you you can use the product in a functional manner and redo oftentimes people do this in staging but now you can do it right with your branch and doing all these things everyone is invited to the party you have more people now that have the ability to to provide feedback they're not going to do a full review you know they may not review your code in this but they could review a piece and it's done here and i think that's super powerful and and provides team benefits such as um you have a greater role diversity in that review process right so content if you if you change even small changes in like login screens and document and just documents on your page or just anything it matters right like we we we sweat the details a lot of times and so being able to see that and be able to show the end product to someone who cares about uh words and phrases and all that is great the design of the page the flow of the page so product can go in and say hey this goes from this to this to this part of your application and goes through all that and they say yeah that's that's how i envisioned it in my mind and they can do that right then um just by clicking a few links on the on the review right um then development they get to use it so if you're developing um an internal api people could target your preview environment with their clients and use that it's it's up there it's ready for them to use um and then dev ops this one is kind of a subtle thing in that with the i think the advent of all of the cloud deployments and everything the dev ops and the uh specifically the automation of getting something deployed things can break then you can go through and make your feature write all the code and then all of a sudden you can't deploy it in a production like environment well with preview environments and specifically preview environments that model how your production environments are done that automation gets tested with your branch if you can create a preview environment it's much more likely that you're able to produce a production like environment so dev ops is now participating just kind of by the fact that a preview environment gets created right um they may not have to review the preview environment but but any automation for putting stuff into production is is now quicker it's just tested right away just by the fact that you created a preview environment i believe that adding all that adding the diverse role set testing all those things adding the visual changes i think that promotes ownership and what i mean by ownership is um i mean having feeling like you have you are responsible for your product that you have a say and that you are participating right and that you're participating in the key role i think i'm biased i'm a developer right but i think the development portion of it is some of the one of the key aspects there's many aspects but that's a that's a place where it's being made is being developed it's being created and so the more people that you can include at that point in time the the more responsibility they'll feel and the increased ownership i think typically leads to better products and better teams um we've ownership gets increased because we simplified the pattern of engagement we've included the review and all the visual review and everything right there with the review process is something that most people are used to when they when they develop code and then hopefully most of your team it is is used to using your application right and so clicking the clicking link or hooking into that development and then consistency so when you are consistently participating in review process because things are now simpler to do and because your role has an opportunity to do so um that's just gonna promote more and more so it just keeps turning that wheel of everyone being involved and then i think critical timing of feedback so uh we're all busy right whenever i typical flow whenever i do a code review as i will do a code review it'll go under the normal let's say that in the traditional sense as this flow shows in the traditional model we'll do a code review we'll check all the traditional code diff type things we will merge and then that gets into some staging deploy and then if there's any kind of visual or integration review that needs to be done it'll be done against that environment right my code's already been merged already went through code review if i have to make a change right if i need to address that feedback what do i have to do i have to go back either get a new branch or get the old branch make that change then it has to go under code review again because typically these are enforced i can't merge at all any new change and so we've sort of in a way disincentivized actually having that because i have to go through this whole flow again and so we're less likely to dot the i's and cross the t's of the visual and the integration review process right because i don't want to have to do this again because i don't have time right is it important enough to where i can redo all of this maybe maybe not and and that's a judgment call that may be true but what if we could remove that and i think with the preview environment the typical flow at least when we're talking about the visual and integration review and and all that sort of thing it becomes this right so we do the code review and the visual and integration review all before the merge altogether right and then we merge and there's no more that the feedback's been done i don't have to wait for another deploy to get more of that feedback there are other things that you will pick up but for the most part we've for this part for this visual and integration review of the actual change we've eliminated that right so we get to do that all once and one branch one go we've i believe save time for um the developer we may be using more time for people that that haven't been part of this review process for we may be using more of their time because they're participating in more reviews but i believe that's a net gain and i think that all those key components you know the role diversity the increased ownership and then just the better use of everyone's time i think those team benefits to me really highlight why everyone should consider preview environments it may not work for you but you should at least consider it because of the benefits we've talked about here today um yeah that's the end of my presentation of my talk on preview environments do i still have time i know we did do i still time for questions okay and i'm going to okay so i've got zero votes but it's the only one up there so it gets uh gets to go um you mentioned the benefits of preview environments for looking at visual changes but it's also great for getting a feel on interactive changes like a search or browser yes um yes so the sort of performance related there's sometimes i talked about in the and i should have mentioned this then but i talked a little bit about how we look at complex code in a different code review we're checking that well why are we looking at complex code i mentioned you know looking for things that may be bug prone but a lot of times complex code is uh non-performant or doesn't perform as well and it may show up in a preview environment especially if you're able to load your preview environment with with data with the last talk they talked about how they because they were database based they talked about adding um data into the database and so that you could do development and they needed for development purposes purposes we could do that here um i think we have one local one oh i was just going to follow up and explain a little bit more what i was talking about you can also end up with like a UI that looked really good when you drew it and then when you go to like click on something like the page reflows and all of a sudden like you thought you were clicking one place and it goes somewhere else and so that's another thing that these preview environments can really help you catch yeah yeah that's a good point thank you thank you yeah so the the point was there that that oftentimes when you have if i get it all correctly if you have a flow or like spinners or something going in between if you actually go through the flow of the website and actually visit you you may find that you've done something you didn't want to do and it's gonna need a change right and you can address that then any other questions yeah we have one right here hey uh i was wondering if you think this method uh would apply only to ui environments or also to like let's say apis or uh command line tools like your preview environment would include only ui tests right yep so the question is uh do you think that preview environments are valuable for non ui environments like like clis and apis that sort of thing yeah yes i do um obviously i think it's a little bit there's a little bit more um harder to integrate a test with that so i didn't talk much about integrating automated tests with preview environments which is something you can do but say you have an internal api right that that the rest of your team users are even publicly available api you can go ahead and either run an automated test suite against that or uh if i'm providing a new api change to say there's like two or three internal teams that use it they can start using that they can target and do whatever you want hey i have a preview environment run it through its paces and give me some feedback right that's now an option um cli is the same you know any anytime there's a client server interaction whether it's htp or whatever if your cli has that way yes yeah i think it's super valuable i think the i do believe it's a harder to adopt right and the the benefits are not as immediate as the ui ones um and the role diversity doesn't apply doesn't necessarily apply as much but you are able to involve more teams and give them a a really high fidelity environment to to do their testing it's before a merge right that's better than doing it stage you can get that feedback earlier and not have to wait for that yeah i think so okay thank you last question uh hi so along the same lines i was gonna ask about the database as well like how would that work but i think i get the answer uh it's only used for ui um previews right so um the question is if you have lots of database type things or database actions how does a preview environment help there yes or is only for ui stuff um typically the the the quickest that i've seen value have with preview environments is for ui basings however that's not the only way right no we absolutely there are absolutely remote uh development products that allow you to populate data for your deployed environment so if uh you know they talked about it last talk where they can populate that data so if there's any type of client server interaction where someone is consuming it which is almost everything right so uh if you are doing some kind of say you're adding a prepared statement i'm not great with databases i don't use them a lot but if you're adding a prepared statement or some change that where the data model is completely different yeah you can you can absolutely model that change and start doing that it's a little bit more you you have a more robust and you have to work harder on creating that preview environment but it usually pays dividends in so many ways you can use that now in your development environment your preview environment and staging and so on right so so basically mock it out mocking it out so basically mocking it out right and no it would actually deploying it you would just deploy the real thing and you may have mock data like fake can data or a copy of of actual data from production sanitize it don't do that unless you know your data right but that's not a recommendation but it it's possible right yeah you you would actually deploy that that's one of the the in my definition that would be fit under that and that it has to be exactly like your production deployment or as similar as possible all right thank you everyone