Configure Once, Run Everywhere

Video in TIB AV-Portal: Configure Once, Run Everywhere

Formal Metadata

Title
Configure Once, Run Everywhere
Subtitle
How and Why to Use a Common Configuration for Dev, Testing, and CI Environments
Title of Series
Author
Contributors
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2021
Language
English

Content Metadata

Subject Area
Abstract
Many of the challenges developers encounter with CI pipelines stem from the fact that CI is siloed from the rest of the development process: • Because development environments are configured separately from CI (and are often pared down and simplified), devs run into hard-to-predict CI errors caused by discrepancies in environments. • Integration and end-to-end tests are commonly available only in CI, meaning that troubleshooting these test failures requires long and inefficient feedback loops—every fix requires a developer to push and wait for another CI run. In this talk, we will describe and demonstrate how to use the open source project Garden to ensure that environments are consistent and predictable at every step of the pre-production pipeline—from development, to testing, to CI. We’ll also show how to give developers the ability to run integration and end-to-end tests during the development process, making it easier to catch and fix issues when it’s most efficient.
Context awareness Service (economics) Open source Common Intermediate Language Moment (mathematics) Projective plane Statistical hypothesis testing Product (business) Statistical hypothesis testing Arithmetic mean Word Integrated development environment Different (Kate Ryan album) Term (mathematics) Configuration space Integrated development environment Configuration space Office suite Computing platform
Statistical hypothesis testing State of matter Code INTEGRAL Multiplication sign Execution unit Mereology Subset Process (computing) Local ring Information security Physical system Smoothing Feedback Bit Flow separation Statistical hypothesis testing Process (computing) Interrupt <Informatik> Configuration space Text editor Ideal (ethics) Quicksort Cycle (graph theory) Resultant Electric current Laptop Dataflow Implementation Disintegration Product (business) Statistical hypothesis testing Term (mathematics) Task (computing) Context awareness Execution unit Multiplication Dataflow Validity (statistics) Inheritance (object-oriented programming) Projective plane Code Cartesian coordinate system Frame problem Loop (music) Software Integrated development environment Personal digital assistant Discrepancy theory Local ring
Statistical hypothesis testing Open source INTEGRAL Graph (mathematics) Connectivity (graph theory) 1 (number) Mereology Statistical hypothesis testing Revision control Mathematics Single-precision floating-point format Physical system Module (mathematics) Multiplication Graph (mathematics) Mapping Military base Run time (program lifecycle phase) Projective plane Interactive television Process (computing) Repository (publishing) Hybrid computer Configuration space Quicksort Object (grammar)
Statistical hypothesis testing Point (geometry) Intel Module (mathematics) Service (economics) Euclidean vector Computer file Software developer INTEGRAL Multiplication sign 1 (number) Set (mathematics) Verteiltes System Mereology Statistical hypothesis testing Product (business) Template (C++) Web service Mathematics Cache (computing) Energy level Configuration space Local ring Computing platform Physical system Module (mathematics) Execution unit Multiplication Demo (music) Inheritance (object-oriented programming) Projective plane Code Bit Instance (computer science) Multilateration Cartesian coordinate system Template (C++) Statistical hypothesis testing Loop (music) Integrated development environment Repository (publishing) Hybrid computer Configuration space Information security Routing Local ring
Module (mathematics) Point (geometry) Statistical hypothesis testing Computer font Scripting language Service (economics) Demo (music) Projective plane Database Infinity Raw image format Stack (abstract data type) Cartesian coordinate system Open set Web 2.0 Voting Message passing Different (Kate Ryan album) Configuration space Video game console Descriptive statistics Task (computing)
Point (geometry) Statistical hypothesis testing Dialect Service (economics) INTEGRAL Numbering scheme Statistical hypothesis testing Voting Term (mathematics) Different (Kate Ryan album) Single-precision floating-point format Task (computing) Physical system Scalable Coherent Interface Module (mathematics) Multiplication Graph (mathematics) Projective plane Voltmeter Database Unit testing Human migration Radical (chemistry) Personal digital assistant Repository (publishing) Configuration space Video game Table (information)
Statistical hypothesis testing Context awareness State of matter INTEGRAL Equaliser (mathematics) Multiplication sign Execution unit Parameter (computer programming) Mereology Variance Medical imaging Spring (hydrology) Mathematics Computer configuration Different (Kate Ryan album) Flag Endliche Modelltheorie Local ring Exception handling Computer font Closed set Moment (mathematics) Menu (computing) Bit Variable (mathematics) Demoscene Radical (chemistry) Type theory Message passing Software repository Internet service provider Configuration space Normal (geometry) Right angle Remote procedure call Resultant Point (geometry) Module (mathematics) Service (economics) Computer file Password Exponentiation Mass Infinity Field (computer science) Product (business) Statistical hypothesis testing Revision control Voting Term (mathematics) String (computer science) Gamma function Atomic nucleus Task (computing) Condition number Module (mathematics) Flock (web browser) Default (computer science) Execution unit Cone penetration test Inheritance (object-oriented programming) Twin prime Projective plane Variance Cartesian coordinate system Scherbeanspruchung Template (C++) Punched card Word Voting Integrated development environment Scalar field Circle Routing Local ring
Statistical hypothesis testing Voting Root Service (economics) Hash function INTEGRAL Source code Source code Voltmeter Port scanner Optical disc drive Statistical hypothesis testing
Statistical hypothesis testing Run time (program lifecycle phase) State of matter View (database) Multiplication sign Programmable read-only memory Source code 1 (number) Numbering scheme Stack (abstract data type) Mereology Unicode Variance Variable (mathematics) Subset Heegaard splitting Medical imaging Different (Kate Ryan album) Source code Endliche Modelltheorie Local ring Computer font Open source Menu (computing) Port scanner Open set Laser Type theory Hash function Ring (mathematics) Software repository Configuration space Self-organization output Task (computing) Windows Registry Module (mathematics) Identifiability Service (economics) Computer file Line (geometry) Computer-generated imagery Control flow Exponentiation Infinity Template (C++) Revision control Voting Energy level Game theory Metropolitan area network Module (mathematics) Execution unit Standard deviation Twin prime Core dump Line (geometry) Binary file Cartesian coordinate system Template (C++) Revision control
Statistical hypothesis testing Cluster sampling Dataflow Context awareness Scripting language Module (mathematics) Software developer INTEGRAL Programmable read-only memory Disintegration Infinity Login Variance Statistical hypothesis testing Product (business) Voting Mathematics Cache (computing) Different (Kate Ryan album) Feasibility study Integrated development environment Configuration space Local ring Error message Service (economics) Feedback Projective plane Open source Menu (computing) Portable communications device Statistical hypothesis testing Sign (mathematics) Arithmetic mean Process (computing) Loop (music) Integrated development environment Software repository Synchronization System programming Configuration space Right angle Spacetime Booting
Point (geometry) Windows Registry Dataflow Slide rule Group action Game controller Scripting language Open source Software developer Multiplication sign Disintegration Branch (computer science) Event horizon Statistical hypothesis testing Revision control Voting Spring (hydrology) Cache (computing) Internet forum Different (Kate Ryan album) Integrated development environment Circle Configuration space Enterprise architecture Computer font Email Inheritance (object-oriented programming) Boilerplate (text) Open source Plastikkarte Bit Portable communications device Statistical hypothesis testing Statistical hypothesis testing Integrated development environment Hash function System programming Configuration space Figurate number Task (computing) Spacetime Booting
Point (geometry) Presentation of a group Group action Building Scheduling (computing) Service (economics) Open source Link (knot theory) State of matter Multiplication sign Set (mathematics) Mereology Statistical hypothesis testing Template (C++) Product (business) 2 (number) Latent heat Crash (computing) Different (Kate Ryan album) Ideal (ethics) Energy level Metropolitan area network Computing platform Module (mathematics) Arm Demo (music) Gender Projective plane Physical law Data storage device Cloud computing Database Bit Instance (computer science) Cartesian coordinate system Flow separation Element (mathematics) Integrated development environment Website Arithmetic progression
Element (mathematics)
hello thanks for tuning in my name is the own i'm the c.e.o. and one of the founders of garden.
wanted to talk today about how and why you might set about using common configuration and tooling between your development and testing n.c.i. environment. in terms of how we will be talking about garden the open source project that we maintain but even if that's not what you're here for i still think why can be interesting to you and also just generally how we approach a garden whether garden is useful for you or not. just a quick few words about about garden so we started beginning of twenty eighteen. for engineers on all pretty frustrated with the developer experience around micro services mother was containers are communities or something else. base here in berlin sitting here to berlin office sadly mostly empty these days and what garden is we provide what we call automation platform for twelve native development and testing the club native it's actually used for a few few other things but we focus a lot in containers and communities. at least for the moment it's open source free to use there's also a commercial product but i won't get into that so much here on and i mentioned we are frustrated with the developer experience or on my groceries and. what do i mean by that so start the talk with some of my top dislikes because by would not so what i really don't enjoy is happening too frequently switch contexts hop between different things and i'm working on i really don't enjoy.
boy repeating the same thing over and over again or solving solved problems for that matter. and i also have a distaste for vagueness both in certainly in software systems and also humans i guess on and you know you might notice that. a lot of these things kind of apply when you're in the process of the bugging something and see i see the so on and that's kind of you know part of a big part of the motivation for starting garden in the first place on what i do like harbor is a flow state where i can just keep or. working on what i'm working on and focus on something that i'm actually meant to be doing without interruption without without distraction i love smooth automation which is really what we're all about here the garden and automation that just you know gets out of a way does what it said. most to do just works. i really enjoy again both with systems and humans clarity insincerity something that i value highly. and been getting into a japanese since pot which you know. i think you'll find actually and combines all of the three other things anyway.
so what is it that makes the current experience around like the developments the icy the develop development of delivery cycle less than ideal i think it's helpful just to kind of frame this a little bit to look at so what a typical sort of a flow on as we work on things. we typically have or you know the story the inner loop where we editor code we were going to id we run our unit tasks as we go. we hopefully you know not always the case but we hopefully have some kind of a local environment where we can actually deploy what we're working on could be talking compose could be some many q dr to stop something like that. and then you know when we feel satisfied we've done what we set out to do we push to get neck kicks off some pipeline on and that's where you know we built build the application properly we run often more tests them were able to do locally on. integration tests may actually happen. in the kind of generals p.r. pipeline but. we often find that happens a little later in the process so i kind of put it like that but maybe this is all part of the same work for you and then ultimately you know after we've really review hundreds we promoted to production so i'm very into of this setup is pretty typical and you know obviously you can be quite quite different. based on your contacts but you just have some frame to talk about here on and to one of the problem so one problem that we see frequently is these local have preview testing environment on are either difficult to maintain its a little bit of extra tooling that you can figure. separately from everything else on sometimes it's simply not feasible to run stuff locally and that could be the case if you're you know some restricted by t. environment in a lot to run talker communities your your project to simply too heavy and you know where the sometimes is not just a matter of whether laptop likes it or not some time. this is just too much coal to run on and but yet certainly it's not implemented the same way as your production deployment on another problem is that integration and two and tests and you know all the time to test as well like you know security validation like you know compliance checks. mostly check things about sword they tend to happen quite late in the process on really to they happen in the inner loop as you're working on things sometimes a you know happened in the p.r. process or subset of them do but just you know going by our user base our customers we find that a lot of. the time people have been doing quite late in the process they have like a separate staging environment as may be shared between a bunch of different users. that's where integration test happen now and in any case the feedback from those tends to come quite late in the process which is obviously not ideal on you know certainly lose your flow state waiting for those and you know extra bad if you're already emerged your code before you get the results for. for those but you know another way to deal with it does not have integration and one test which is pretty common as well but that means you're left with either less test coverage or you have marks and stubbs that you also need to maintain on and they also makes assumptions honor code so on. it's in any case not quite ideal. as i mention and you know i will mention again debugging failures like what you know in this process and see i can be incredibly tedious and tom you know it's the if you have a bunch of things that only happen in cia or not people to replicate locally you often find yourself. selves in this super tedious feedback loop again and again trying get pushed you know until you get get it fixed and that's something that a friend's mike years at least on and it's very common as well for the tooling to be all kind of separately configured across the state stages so. so you know most commonly you have at least two two different set up you have one for the in a loop on and maybe one for the rest on but is also common for you know you have one thing that's going on and c.i. and another thing that's going on you know in your staging production environment in terms. the tooling and configurations so you have to configure everything multiple times. is going to be fiction and discrepancies between the between the different faces on and on than those can be annoying and tedious to the park. so and only on the these problems obviously just get exacerbated the more individual pipeline said you have and you may have one percent of us or you may know have some usually we have multiple pipelines and to deal with hopefully not like out a full locals. that up for each and every one of them although we have also seen that but on the more you have to maintain of these. the more they differ in their implementation the the bigger the problem so how do we approach this at the garden and with garden.
what we set out to do when we design garden was make a tool that's sort of hybrid between development tool and automation tool on so that we could configure our project ones and run it run anywhere for development testing cia and even production as well. so how do we go about the central to it is something that we call the stock rough and so the way you can figure garden you can configure every component in your in your project and the graph bases so cardinal aggregate all of that into the graph so on with car.
when you're able to codify not just how every individual components built deployed and tested importantly on your also able to define what depends on what and this basically means a and you know that was the objective that you can run from a single place garden deploy and it will. ploy the whole thing we can run garden test and will deploy and test the whole thing from start to finish from a bunch of get repositories or just the one. without any further interaction from the user and and the depends a graph not only gives us that but also because garden will not so for every say module in your system which could you know not to a container for example we know which source files. this map to each of them on and the configuration and we will have close together to do to get a version the current version of that wealth that off every note in the graph and we use that so that when you make a change to request a comment on whether it's a single filer multiple we will figure out what. actually that impact so which individual note impacts and then what's below that in the graph so we can figure out which precise parts off the graph need to be acted upon so that you don't have to run the full battery of builds deploys in tests for every small thing that you do which is another. common problem with you know especially if you doing integration tyson and in a sea of public. how you actually can figure this so another thing that we decided early in the process was that we want our configuration to be distributed much like our system so on generally every part of your project describes itself and this is how and deployed built and deployed i'm test it on and what.
but each of those steps depend on. and you can locate that with with every part of part of a system whether it's in multiple repositories or in the single one on this bit of the animal i don't mind gamble personally as long as it doesn't have let you know twenty levels of indentation or something like in the communities manifests oftentimes on so you can you know it's. it's a little bit more tractable you don't have these huge files that not monolithic configuration for distributed system which can be quite tedious and to make that feasible we have a quite powerful time playing centex i'll show you that in the demo later. and you can also define your own obstructions you can do to find templates for the individual or sets of modules and that super hand the like you know if you have scaled s. ariz our platform teen on to provide that to other developers who may not care so much about you know how you write a company's manifests or. something like that where you can take in some you know this is how it should always be done for every web service the pair service so on and so forth. doing more of this little later on and so heartening to see a light tool and the ideas that you can run the same commands both during development and from your see our problems. and it doesn't matter which sea ice system use the idea is that you can always just run garden deploy a garden test with just different environments which will trigger some changes in your time plating were deployed to a different cluster you can use the same cost or for both development and testing on the nice thing is that on. if you're sharing the infrastructure whether it's for all of that of and c.i. or just for the developer separately and then the sea ice separately you get a cash that is shared between all the different instances of a project so when you run garden deploy generally the developer will get its his his or her own. no names based on and. and the same goes for individual test and pipeline routes so the idea is that when one developer has built something or tested something another developer doesn't have to do the same so on basically shortens the time for every individual run of carbon tests are going. the point where any other command for that matter. and the idea basically waste less time on waiting for c.i. debugging c.i. on both because you use the same tools same configuration and also you get the benefits of cashing across the two. so here is this all kind of visualize together so garden being a hybrid between developed and developing tools they use for the inner loop and the automation to the news in your c i see the pipelines on stretches across both we have i mentioned that some people on also used to. the point of to the production your mileage may vary on and when i'm developing i can easily run carbon deployed at my home preview environment on that will work the same way as one if you if you do the same from c.i. create a preview environment that no other developers are key way can really give you an preview the changes. on i can run integration and twenty s. anything else on which actually run inside the environment so those tests can address services in the environment on those can be run before i push to get on and even if i don't run them before of course to get if something goes wrong in see eye on. the test that around here are the same ones that i would otherwise have or run in the local development preview environment so you know whichever individual thing goes wrong i can more surgically run that specific thing on locally and the bucket much more rapidly than having. to do look at commit push you know save commit push again look at the locks and c.i. over and over again. so it's kind of the basic idea going to show you how it works.
this thing around here. so we're going to use a simple example project for the demo lot of example projects here in the garden corey ball and i will and take take a look at a couple more on his part of a dental but will suffer this one it's a simple it is simple application and spin.
off the doctor compose voting example that you might have seen at some point we have a a.p.i. back in service posters database read his message q couple of web you eyes and back and work or won't take too much into the actual application but. but it's yeah it's a fairly basic consolation of things you might have been a project. before you dig into the configuration. just to visualize as a little better i'm going to start the garden dashboards process. which will spend about simple what you i that's handy. for development but certainly for their own purposes because it helps as visualize so you can see all the different components with and their descriptions different modules that contain services and may define tasks or tests and here you can see it in the stack raf so.
the stack of shows all the individual steps required to go from a bunch of cold and configuration to running system whether it's in a single repository or multiple repositories cardinal compiled this based on all the only individual can fix so generally something needs to. to be built before it's the point i hear you can see an example of the task the knees renaults so before we started playing more testing services we want to this case we create a couple of database tables this could be running a scheme of migration framework. the loading some test data whatever the case may be in your case and and then as you go down you see more and more of a test not so your unit test nodes made just depend on something being built the integration tests here depend on something being running so unlike the volt integration test needs the volt service to be running. and so on and so forth. so hoping fact of the term terminal here we're going to do is to floyd the project so garden the sea life has lots of different from the commands there's got to deploy a carton task garden filled you can deploy a individual services were test individual modules can see it here to reversing the graph. and this is also visualized here in the dashboard on and you notice may notice year many of the services are already deployed so garden will check the current status.
near to redeploy the voters so we can see kind of the communities status is being reported waiting for the health check to pass you see the individual in crests euros that we define as part of the services when you run this and watch mall it also creates port for words for you automatically. which which can be handing so now the second point. how does garden know what all of this is so let's go and look at the conflict so starting with the project configuration so this generally is what you put in the project route. often in the repo reaper route as well. this is kind of the entry point into the application so we can see here kind project on we define the environments are so we have here on local environment for development and other remote one also for development and then stage stage and prod you know he can name these whatever. basically you can and you can define as many or few of these as you like just for the sake of examples you know obviously this is not a production application but define this year and four environments of production environments or other environments that you want to protect you. you can define this flag it will change some defaults in terms of how how garden generates by companies manifests if you're having garden do that it also as a confirmation step so if you do garden deploy and prod him. it will unless you put another. command line argument in their evil ask you if you're short so that's kind of handy if just make sure that you don't accidentally ruin something if you have access to it to begin with so so the environment. i'll get back to the variables in a moment we project also defines providers so for the local environment we have the local communities provider which is made to work with like minute you talk or desktop kind of cetera and then we have the normal companies provider which just connect to any current is close to.
basically and that's used for the renault stage and prod environments the context we define here is a variable see completed reference to not and were also directing it to use built kid to home built in the costs are there are other other ways to build and cost as well like an ego. so that's kind of out of school for this particular talks on and the eye can see hear how we define the remote context variable this is just pointing all the are all these enormous just pointing at the cost or. we define a user id see an example of how we can use conditions here carbon supports pretty complex conditional you do like turner is eight months and you can do all kinds of the different things you can check for equality and. and pick pick a value based on that committee find some examples of that later and then this variable is used in a few different places here here for example where the defining what's the base host name that we use for the increases for the service is a little bit differently based on which environments are so these. variables are defined globally for all environments and these are the over rights and you can apply for individual environments you can also use template strings to pick a value based on which environment you're in like environment out name equals this then you use this value otherwise that value on. so you have a few different options their the variables can also be placed in separate files so you don't end up with one of those massive configuration files that we talked about so you can have one on one var file we call them for each environment or and one for the project you have several options there. they're too kind of keep your configuration looking nice and clean and scene and. right so that's a project configuration now let's look at the modules so in garden parlance of we have the project and then we have models and modules can contain one of her services or tests and or tests or task so here for example we have some have a pretty simple container module. still there's no talk of thousand of building it were just fetching based on this image field here so it's kind of similar to dr composer not regard to. and it also defines this particular service you can have multiple if you like on and this you know this obviously is fine for just development suppose it's kind of an out another close to doing something dr compose and i will later show you how it in a somewhat more realistic example which uses a. i'm chart on in another example project which is basically the same project except for using helm and this may be something that would be more realistic if you're actually creating production like environment. and maybe a slightly more complex example here in the a.p.i. service so here we have we have a talker phone next to it so we're going to build this again a container module type lot of different model types and garden and will show your couple more on. on the other services to find a few more variables here to find a health check so you can see some kind of communities terminology. millions in tax if that's what the that's what you using on could see an example of how we interpret late attempted variable into a string just pretending on and on the base host name here there's a long time dependency on the red his message to and hears. perhaps the interesting part so we define couple different tests the unit tests is just a dummy tested always always passes but the integration test is an actual test that. is defined here so we just passed different arguments to run in the same container. and this test depends on the a.p.i. being running so this tells garden not just that we need to deploy the a.p.r. service first but also if the a.p.s. service changes garden will know to retest so now let's hop back to the terminals already deployed the stock now going to run garden test actually. the this will complete pretty quickly because i just ran this a little while ago and those tests have already passed so there you can see how cardinal test it's already cashed the test results. but what now if i break the tests so the actual test just expects a particular state is cold coming from this super basic flask by phone service here so if i have a return some i don't know what that saves called would mean but.
and then run carton test again. garden because it's a were like you know which source files and belong to which module on cable rican putis hash here and you can see in a few different places and it knows that it needs to rebuild the a.p.i. and then anything that depends on that including the tests and other.
services that depend on the care service needs to walk through these again so here can see the test broke and you also do the same for the volt bolt integration test because the effectively the same thing and you can see the lot here.
and you can also never get to that here in the dashboard.
so this is a pretty of course a kind of basic example but you can see this is basically how the stack rough part of garden works it will generate a new hash based on the actual state of the source files and the configuration.
attached to going on break this and we can move on to couple more examples so. all the time playing in this one for example a super straightforward but if we go to the helm version of here you can see we've split up each of these services so we have. for this a.p.i. service we have the a.p.a. image which notice doesn't have a service is key it just takes care of the build and then which tests we are to have on in this container and you could also define these tests in the helm chart that references this image so. on the few things to cover here so this is a whole model type we have something called a base chart so we were using the same helm chart that we define here for multiple services you could also define this in line you could just have the helm chart files here for the a.p.s. service if it's you know. it was not a man to be the same as the other ones can see here we find the runtime dependent see and hear a passing values to the home chart on and here's a good example of how you reference across different modules so the a.p.a. image module on to find some outputs and that. to find that the module type level and one of them is the deployment image name so basically so that you get the correct the image identifier. of this big it's important to references in a tempest ring because this will be different based on like they are deploying locally are you deploying you know is a container registry in the next that you need to address somehow and this is a is a clean way to do that and then the tag will be the version of the module. so that's yeah slightly more elaborate template ing. and eight yeah i invite you to actually go and look at this to see how it works another example here you referencing up upstream helm chart just provide the repo the chart name version and you can do the same with a value this year the contemplative in whatever makes sense to template in on. it mentioned in the previous lives the notion of the module templates so this is super handy especially if you have your kind of view of a subset of your team organization that does you no no's communities and the other one is maybe you know the application developers are not as well versed. you can define a template. and then use the template module type so here this is pretty easy to understand it's a company's container in this could be whatever you to find it expects these inputs and the way to find this template like this you it's a different kind of model temple. but. you feed a scheme which is just the standard jason schema he can find that however you like. and it will create these two modules and this could be however many like it will generate some files you can even do here we're generating companies manifests this could also be you know you can generate a rockefeller can generate whatever file and garden will do that when this. basically when you use the template of module and references template garden will generate the files so here for example we have set of companies manifests and you can see how were the referencing inputs and doing some here is like here's an example how we can do nest that the.
template references and yet so there's lots of different things you can do if you want to obstruct things away from developers or kind of centralize how you define companies manifests this is one way to do it and you're so lots of lots more examples here i think i'll leave it at that for now. but by all means if it's interesting going look at the examples in the repo and the documentation. right so just to summarize.
and what you get out of this year is you're able to run garden deploy for any different environment and get like a production like environment on and we think that's very important because you get much higher quality feedback. early in the process you're able to run tests within the project named space you can actually feasibly run integration and two when test and you can actually are we can feasibly write them too because if you're only means of running integration test our through your c i see the pipeline on. that makes them super tedious to implement to begin with and that's why a lot of people just don't which i totally understand i wouldn't want to know have a like a ten minute feedback loop for every little change to make to a test on but this now makes that feasible. you get out of this super tedious loop of you know it commits as the of a sea of and porsche hope for the best get that acts in your and your see a pipeline look at the logs figure out what you know you think might might be wrong hope. fully you have good error logs maybe you don't on and then rinse repeat over and over again never menacing to stay in flow on always just kind of context which ing going for more cups of coffee and slowly losing your sanity in the process at least i do. side benefit is that your bill test and deploy configuration on actually that reminds me wanted to show one more thing.
so here is the cia pipeline configuration for so this is circle see i could be whatever on and you know there's a little bit of boilerplate to connect circle see i have educated with the costs are on but the pipeline itself the work flow is really just this week check out the branch weaken figure the costs. there and then run garden test and just pointed at a different environment. and that's about it on you know here we also run clean up whenever the test is done whether failed or not you might also want to keep it around it fails so that you can keep our get whatever makes sense for your work flow garden enterprise has a nice features for this just a tiny little plucked there but. but you can also the yachting you use give actions you have a lot of control over the different events and what does what. and this command you could be running from. yet which ever see i run or just point in a different environment and work just the same as when you're developing it yourself luckily so again back to back to the slides.
and yet once more like you because you're or and not just building everything locally or running stuff locally if you're running things remotely you get the benefit of having shared bill cash is on both through the container registry and also in the inquest of builders and the. and you sure test cash as well because of the way card and does a version ing and hashes of all the source thousand convicts. ultimately this means on shorter wait times and see of pipelines even though you can be doing much more in the pipelines on fewer hours spent debugging and you know i'm in the tedious kind of low value plumbing work that you might be doing that isn't really what you started your. victoria company do on. and you can stay focused same flow and on and just be generally a more pleasant than happy person and the science. yeah so that's about it on to dig into the garden you can just look at our talks or are get up and oxycodone that i was a good place to start or a website garden that i owe on we just launched a new community forum and would love to hear any thoughts any questions. whether it's you know before trying garden or after trying it. anything goes super happy to chat there on we are like anybody else of course hiring on in particular were looking for an answer he was some could experience. and they are you have also my e-mail and my twitter handle super happy to hear from you on just talk about the general problem space or garden or whatever else don't hesitate to paying and that is about it over to the chapters q. and a and thank you.
i.
you're getting old.
our and your career. the same week we told me. shortly. it all post a link. and we are. it's. thanks for this for. the new inventory and things john for giving a presentation book garden and the open source projects. definitely a very sweet spot was often only of quantities birds arm and and told the develop experience of about any platform this really is something you arm which often next especially with one of those like very low level building was like when it is which. she's very kind of illegal. the point is very hard to get right so. so let's a really good like project your working on on. on new lives a couple of minutes for people to join the group. from the room. but maybe we can already started to have on one of the questions on. be are interesting to know would be like how you manage a major difference between an burns on light off a cloud infrastructure that in use during development or down. well yeah i'm so i guess we didn't really get into that in the demo so one thing that you can do that i didn't mention is you can have like some modules in your project are only in one of government are not in others are hands and same with the individual services are you can talk of them on or off site being able to configure the so critics on. oh i guess another thing that i did not mention i think. the garden support both companies and care reform and potentially other things in the future so one typical example that's something we do ourselves for on developing this wall is like having a like a man it's like in a post like at r.b.s. and that's preposterous or something like that some carter called gender specific thing. for staging of production and four like you know like the smaller to test environment you have like a basic like hostess like ephemeral container instance or just use a culture that's pretty common and basically being given because we support her home you can do almost anything. i don't you know outside of communities. and that's of course not even considered like i think of projects to allow you to deploy improper a group that is of course so you have lots of flexibility other. and yeah the progression is usually like you have and of simplistic environments for like in a look that of and and more realistic as you get the staging an auction. that's kind of that's how we approach a general. how do you live on like one of us to share the tendencies. i just know i believe in all environments are loaded on to contain for example sometimes there are churches tendencies move which you can only use instead of stunning as their and the idea is the current issue on to let rich those so what we need. she people who is having separate like a separate curtain project for shared infrastructure alone and and we have designs on. like more natively supporting project dependencies so you have you know anything shared for like devon testing and staging would be deployed in one project and then that kind of template into another project people to get a little bit more granular now often using on. workflows which is another feature on where to find the steps like and that can include like setting up everything related to a project. now how we approach it and you know it's it's just so specific the individual occasions like you know our in our the shared services stateless are able to like run as seconds the same database where do you have to have it in a separate you know week we think a lot about these things and ideally. you have an a and ends in your application so you can share infrastructure without best kind of colliding in terms of state. but sometimes you do need to deploy to just like a separate that a store states and communities in the second that's the hardest part really. it's really complicated try it. usual. archie. being right. this is the kind of expensive too. from to run all this kind of different environments that the same time austin the not. in all. i mean i think so like what you just mentioned like having some shared set of services that you aren't really expected to be working on and then don't have to be redeployed for every individual environment that's one way to tackle about another is. so obviously we can't let you know the different environments are you like your haven't passed the garments of norway's smaller resource requirements usually because they're not actually not exactly dealing with a lot of traffic also ephemeral so you know he did you just run garden believe environment like for anything that you have been running. and you know not really here to pluck the commercial product that cars have teachers or automatically sitting down environments but they're also consort projects that help with like you know sitting down age based on a schedule of things like that psyllid they are not left lingering. and not being able to easily over them that way is certainly helps and lastly so for a pipeline or let you know where to park on bond or just you working on something i just showed in the demo like garden deploy garden festival on the whole thing. if you say like referencing the example if i just do like garden and deploy a.p.i.. it will or contest a.p.i. it will need to play the eight has service and what that the law and just ignore the rest of the crash so you can be more specific in which parts of the stock are deployed when you're working on it.
Feedback