Hello, everybody, this is just Reach's Adventure and Devil. Will you already laughing at me? You can't put me on the spot? Do the intro? Now they're laughing at me? All right, Well, I'm Jillian Rowe and with me this week is Will Button and Jonathan Hall Highouse.
And technically I'm laughing with you, not at you, because you were laughing too.
It's okay. I only felt a little bit put on the spot.
I'll forgive you some day to be fair.
I did say okay, let's go and then hit record.
I'll stand with Billian that she was put on the spot, but I fully support putting Billian on the spot. So, yeah, what are we talking about today, guys?
All right, we're going to talk about c i CD tools. What do you use, what do you hate? Why did you use it? Do you get a choice? Does your job just like dictate it for you? Or do you have like some kind of some kind of input into this decision? Why would you make your decisions? Who wants to hit us up first? And I think you suggested the topics, so she gets put you on the spot.
Now, okay, yeah, so it's a big topic. So the reason I thought of it is earlier this week was last week on LinkedIn, one of my contacts asked the public which CICD tool would you like me to use? In a demo about how to get started with CICD, which led into a bigger conversation of which ones are people? And she did a poll which gave four options, and none of the four options were things I'd even used before,
and I've used probably a dozen of them. So that just goes to show that there's a huge selection of tools to pick from. And I don't know how she chose her for but I think it was Jenkins and whatever AWS provides, and maybe Azure DevOps and I don't know what else. You know, it's a good conversation to have. I think, how do you choose one of these tools to use? Because there's so many and they all do
roughly the same thing. They all automate the running of tasks, which can be running tests, building software, tagging releases, ordering pizza perhaps whatever they whatever they do, they can they can automate these things. So yeah, I don't know how we want to tackle this. I mean, if somebody asked me quickly, Jonathan, what CSD S will do you prefer. I have a quick answer to that, and that is
get laud ci. But that's not a very useful answer without a lot of context, because that's not the answer I would get to everybody. And if ask me what should they do, that's a different question than what do I prefer? So, yeah, I don't know how we want to tackle this today.
I think that I think there's like two different ways to answer this. You know, there's I'm starting out choosing a CICD tool, and we have a CICD tool in place and we want to replace it. And for that latter question, my go to response is always don't. I mean, they all have things that they're good at and bad at, and the cost of transitioning from one to the other.
There's just not enough value in it because you might solve one specific problem, but you're introducing other problems that you don't know you have problems with.
Yet I tend to agree it's.
Always a trade off. Yeah, everything like that is a trade off.
The best CICD is the one that you already have installed.
Usually. Yeah, So there are times when it's appropriate to change, but not for that reason, like if you're changing from at lastly and to GitHub for example, you maybe need to change from Bamboo to get hub actions at the same time, but not because you want to change your CSD tool, just because you're changing everything else simultaneously, for sure, So I would almost I mean, there have been times when I migrated off of a CSP tool, but there were cases where it was not being used properly or
being used very little, so that there was very little invested and it wasn't doing much for us. So you know, it was basically a proof of concept that we decided not to continue with, if you want to make up that way. So that's a different scenario than I think what you're talking about. If you have a CICD configured and already doing some thing valuable, I think really hard before changing, really really hard. When you when you're done thinking hard, go think hard again.
I think there are some good stories behind these opinions. You guys have a like emotional trauma to share around switching up c I S peoples and then realizing it was it was a terrible, terrible mistake. Or clearly you guys have never made such a mistake like that, right.
No, No, I thought really hard and decided not to do it.
I've I think my experience forming that opinion has been from not from switching, but from having exposure to several different ones, Like I've used git Lab, I've used Jenkins, I've used Circle CI, Travis CI and all of them. Like,
I can't see the value. There's a fe use cases for it, but I can't see on the surface the value in switching from one to the other because I've I've used a lot of them, and each has their own strengths and weaknesses, but enough to justify rebuilding all that stuff, especially if you have like a lot have it doing a lot. You know, if you have a lot of different pipelines, that's going to be some pain. And at the at the end, you know, what did
you really gain? What value did the customers who are buying or using your product to get from you switching the CICD solution.
I want to add to that. And there might be times when it's appropriate to change, if you're using an anti antiquated tool, for example, or it's just too slow or it doesn't integrate with things you're needing to do. But if you go that route, don't change everything at once,
just implement the new things you need. I know that there's the engineer and every one of us hates this idea of maintaining two systems, but it's worth it versus trying to do turn to ram everything of the new system and breaking stuff along the way, just to admit you're going to maintain two systems, one for the new stuff that immigrates with the Raspberry pies or whatever weird thing you're trying to do, and the old one that manages the old stuff.
Cool. Well, what about somebody who's switching to or not switching but starting clean slink projects CICD tool. What are kind of the scenarios where we would choose one or the other. I have one right off the bat. If you have data or some kind of data or software that have to be private. There are scenarios where you can use the open ones like GitHub, GitHub, circle, all that kind of thing. Most of them now, I think, do allow for at least some actions or like CICD
minutes or I forget exactly how it's metered. I think on GitHub it's tide of the number of actions or the number of minutes. I forget how much for private repositories, but it's often quite limited. Unless you're on a public repository, so that could be a reason to change. You're like, Okay, we have this heavy duty workload. It has to be private for some reason, so either we need to take get hub a bunch of money, or we need to move it onto something in house like Jenkins or get
lab that's managed internally. But really that's it. That's the only differentiation that I make because all my stuff is in make files anyways. So I can be on GitHub, I can be on Jenkins, be anywhere because it's called colin make, you know, like make tests or whatever. Then there we are.
So my simple answer is use whatever's easiest to get started with. And if you're using GitHub, that probably means to get hub actions. Pre using git lab it probably means to get lab CI. If you're using Bitbucket, it probably means Bamboo. If you're I don't know when it would ever mean Jenkins. I can't think of a reason to start using Jenkins unless you're already using it. So
do you? Uh, Maybe you just want to become a Maybe you like pain and like to learn old systems because it feels fun, like, you know, get a Commodore sixty four at the same time, why don't you.
You can on a Commodore sixty four?
Can you? I'm sure you can't, but it sounds like a good project. I think I might have to learn Jenkins and Commodore sixty fours now. So that's my short answer. However, So that's what that usually means. If somebody takes that at face value, that probably means using get hub actions because it's it's easy. Most people use get hub their coporate actions. However, I think get how Actions is actually a really bad tool. It feels like a version zero point six of get lad ci, you know, it feels
like it has a lot of rough edges. Still, it's not really intuitive to use yet. The one killer feature it has over get lad Ci is is this sort of pre bundled ability to just PLoP in other people's code, what do they call it their marketplace. You can just you know, choose an action from some random person off the street and start running it. It also strikes me as really dangerous. It's like it's like n PM for for get houb actions and who wants that? Really? Right?
I just picked up the Helm release from GitHub Actions. There's I don't know what the doctor doctor builds push like that's the that's all I'm doing.
So if you don't care about security.
Well see no, if you care about security, I still think you should be hosting it in house. That's I think that's well.
There's different aspects of security though, I mean, yeah, I mean it depends how much you care about security, right, But I mean if you don't care about security and you want easy then maybe get have actions is fine if you don't have to edit them yourself. If you need to edit them yourself, then the learning curve goes up really quickly compared to just picking something from the at least and Yammel and and more than that. I mean,
JavaScript isn't the hard part. It's it's the format and the way the different actions interact with each other and trying to tie puzz them together. So if you need something more more customized, I think get lab CI is far easier to use and get actions for simple things, either any of them will work. I mean, if you're just writing a cell script, you can do that anywhere now. But if you need something more complicated, I feel like get lab is easier. That part of that's probably because
I've been using it. Longer, so I have the mental model better in my head. But I've heard many other people say the same that they feel like get lab CI is more mature product and get have actions that probably won't be true forever.
I explicated, like you have to build for a bunch of different hardware, so you have like really complic matrix builds because I'm just running make tests like the time, like make tests the doctor build and that's.
Yeah, if that's all you're doing, you're you're pretty good to go. If you're trying to deploy to Kubernetes at the same time, you know, if if you want to automate your deployments to Kubernetes or to Heroku or to whatever, then to Firebase, then you have other things that need to be done. You need to integrate your your authentication with those things. So you know, there's a certain number of complex steps that need to happen. If you start
to do interstep dependencies, things get complicated very quickly. In other words, say you have five repositories and they each film an artifact, and then whatever one of those is updated, you rebuild a master artifact that takes you know, those libraries and compiles of together the single thing and then deploys it. So things like that they can start to get complicated quickly. And no doubt you can do any of these things with any of the tools. It's a
question of how difficult. And this is why, going back to Will's earning point, if you already have this working, for God's sake, don't redo it.
Yeah, I think about these like really specialized CICD tools that I'm starting to see pop up. So we were talking a bit before the show, as we do before we press record, about this tool that I'm using called Spacelift, which is I think it's kind of supposed to be like terraform Cloud, except hopefully hopefully less expensive for me
and my wallet. But no, no, I'm kidding, Like it looks good, but it has these sort of like managed terraform environments, and it's very specifically for people doing terraforms with care about security and policies and maybe building different terraform modules and also protecting your like your stacks as well, so you can insert these policies to you know, say don't kill it if this happens, or kill it if
this happens. Like these kind of things that are very specific to deploying infrastructure, and I think now GitHub has one maybe for JavaScript or for CI like you know, like I don't, I don't know, but I do feel like it's kind of a trend to see these more very specialized CICD services pop up for particular frameworks and code tools and things. Are you guys seeing that too?
I haven't, but I'm the work I'm I've been on stainly has been pretty generic work, you know, not anything specific that sounds like it's pretty pretty siloed to address a specific use case. And I can imagine if you're in that use case, you're feeling that pain. But if you're not in that use case, then you probably don't know that it exists.
So I have not used any specific tools like that, but I've definitely used things that are intended to plug into an existing CICD tool or pipeline for specific needs, you know, simple things. Sonarchy was an example, or depending on the Textec you're using, you might have specific linters for your for your language or your tool set. You know.
We had a guest on if you want to go talking about doing this sort of analysis for Kubernet's manifests and you know, so that would be a tool that you could plug into any CICD pipeline, whether it's get hub or get lab or genkins or whatever. So I've used a lot of those, and you know, so you sort of build up your pipeline with all these different tools. Some of those sometimes are are more sasas than like a tool one that I've used is called coke co
or other co covered tools. Cover alls is not the one where they just do like reporting of your test coverage stats, but they usually have a thin hook into your CICD tool that reports the stats with a mainline tool or over a STAPI or something like that, and then you log into their web interface to see all the fancy reporting you do. So that's kind of a hybrid solution there. You know, it's a stable one tool,
but it hasn't hooked into your existing thing. I think what you're talking about is more of a holistic thing for a specific use case. So I'm not mistaken, And it sounds like it more maybe applies more to like a low code or no code type of product, or maybe not product, but like problem solving. I don't know how, I don't know if I understand exactly what you're saying.
What I'm seeing is a lot of enterprise companies that are having trouble hiring people or maybe just don't want to hire, you know, like as many people as they need, and are starting to outsource to these different agencies and different services. So instead of hiring their own Terrorform expert, they're going a Terraform cloud and signing up for whatever the highest SLA plan is and getting some kind of
support through that. So I'm not even sure that it's so much the software as it is about to support, to be honest, you know, like when I'm actually looking at it, I'm like, ah, which way is that? So I don't know. I don't know because I'm still pretty new to these kind of things myself. I am checking out Spacelift for some of my like for some of my stacks and things, and it does look like it will be good, especially after I had a very expensive AWS bill a couple months ago last month that wasn't
even a couple months ago. I've just got like, you know, I'm still upset about that. So that's kind of what made me start. That's what made start looking at this kind of thing, was that I had this really expensive AWS bill, and I was like, oh, maybe I should make sure my stacks are actually getting destroyed when I think they
should be getting destroyed. And since I just had a two thousand dollars AWS bill, maybe it would be worth me throughout a couple hundred bucks a months at it, because that's I mean two thousand that's ten months of spacelift while I'm looking at it. So I don't know, I'm still figuring these things out too, Okay, anybody thought I had any answers? Answer is no, I don't. I'll just figuring along.
I'm curious to hear what's CICD tools each of us have used, and maybe just brief impressions, you know, if you liked incoins or not likedcons and why you know, in a sentence or.
Two, I love and hate Jenkins. You know, Yeah, I've used it quite a bit. And the thing I love about it is you can do absolutely anything with it. And the thing I hate about it is you can do just absolutely anything with it. So I like, yah, yeah, yeah, I had a scenario. I know this is longer than my two sentences, but I'm gonna do it anyway. That a few years back, I was working with a company, and I think this ties into your statement about which
c ICD you know do the simple one. We had one We were moving this application from Heroku to AWS and Heroku has their own pipeline tool that works really, really slick, and I wanted to in moving to ABS, I wanted to make sure that we didn't lose any features, and so we went with Jenkins. And the scenario was, you know, you would write your code, you would push it up, you would run the tests, all pretty straightforward stuff.
But then when you opened up a poor request, we would create a poll request environment, so we would spin up the Docker containers, provision the databases, create the load balancers, create the route fifty three DNS entries, all of that stuff so that anyone who was reviewing your code had a working environment to see what the actual end product
looked like. And then when that poor request was either merged or closed, it tore down that environment, and that kicked off the build process to build the Docker images, pushed those up into the ABS Docker registry, deployed to the staging environment, and all of that kind of stuff. So it was pretty There was a lot of moving pieces and nothing really had the ability to do that without writing your own Python accessing the photo three library.
And so that's where Jenkins came in handy, because you could just give it this application or this code that accessed Boto three and it would do it, and then you could secure that with im permission, so that Jenkins only had access to what it needed to, which was still a lot, because it had access to S three and rds and firegate and Route fifty three and the load balancers and all that kind of stuff.
That is cool, though Human in the loop, well, I like it, yeah, And.
The part that I hate about that is when you get to that level of Jenkins, you know, you write your Boto three stuff, and then you have a Jenkins DSL that knows how to call and access that, and when there's an error in it, you get a Java stack stack trace, so a Java stack trace that refers to a DSL that refers to a Python Vota three library, so that any error messages you got were just adsbsolutely worthless fascinating.
Have you used any others or is that really the main one you used?
Will That's the only one I've really gone deep with. I've used a Circle, CI and Travis and get lab, but all for just really a high level basic CiCe stuff, nothing that extensive.
My first introduction to CSD was a Travis. I was working at a company several years ago where we actually hosted our own on prem Travis Travis Enterprise. That was the first time I used CI, and I really, I really liked it. I later came to prefer the get lab model, which maybe Travis has changed since then, but get lab has the concept of pipelines and Travis didn't really have that concept. So I prefer the pipeline approach.
In fact, if somebody was an asked me, how would you choose a good CI tool, I would say that could be the first thing. Look, so does it have pipeline support because it doesn't have to. I don't know if Jenkins does. I don't know if he uses that model. Okay it does. Yeah, well that that model is available. Like you just log into Jenkins and point and click your way tout success. You don't get the pipeline model, but there is if you write your own pipelines, and
that's what we did there. There was a we created a Jenkins library that executed the pipeline and then each development team had a YAML file in their repo where they could specify how many running containers they wanted, the memory and CPU allocated to each doctor container, and for auto scaling, could specify your metrics of whether you scaled on memory, CPU, or latency and what that value was. I've also used Circle a little bit on one of the open first projects I help with, so I don't
have extensive experience. My main experience with Circle is that I find the dashboard confusing, but that's probably just because I haven't used it enough. I've also used Codeeship at a company several years ago. I didn't really like that one very much. We actually migrated from Codehip to Travis. We broke all the rules that we'll talk about it. Wait.
Actually at that company, at that company we had we were using like three different SI tools, like each team would pick their own, and so it was more of a consolidation thing than it was a real migration. And it wasn't doing anything complicated. It was doing what what Dillian talked about, basically, make test and make build, and that's kind of all it did. So I also used, of course get hub actions and get lab. I talked
about both of those. There's probably few others I've dabbled with, but those are the ones I had the most experienced with and and the main reason I like get lab is because, well two reasons really. The first is I like the pipeline model, and second is I like to get lab interface in general. I feel like it's a more complete solution in gethub, although GitHub is catching up since la Kasoft's acquisition, they've been adding a lot of new features. But yeah, so that's that's my experience.
I think. Yeah, I've used all the kind of all the big names. I've used drinkings when I've used something in house. Travis, I think Travis was the first one that I used for like a big open source project because we were using Travis and that's it was there and we're I think it was it was probably one of the first, like I mean, I kind of think it was one of the first like publicly available ones right that was free, that was available for open source projects.
So we were on that, and then I think we switched to Start because the Circle guys were throwing some cash at open source projects, and you know open source projects, we always need the cash. So we're there. And then actually I've been kind of, i suppose breaking all the rules by kind of rolling a lot of my own solutions lately, which is that I do a lot of this.
I do a lot of like human in the loop and things that specifically need a really specific, almost editorial workflow where there has to be at some point a person who approves something, and they can't like they're scientists usually, so they can't you can't give them like a stack trace, all right, Like that's not okay, we can't give normal people stack traces, all right, Like we're we're not doing
that over here. So you know, the one thing that I've really been liking lately is to use I'll actually use airflow Patchy Airflow, which is it's a workflow orchestration engine, so it's I mean, it's there. It builds basically data pipelines. But then because it's built on Python and flask, which is a like a web framework that I'm familiar with, it's really easy to build like plug ins and additional
interfaces and things like this. So let's say I have, like, you know, one of these pipelines that's generating tools, and then one of those tools and then another tool will generate some kind of QC metrics on this pool. At some point a person has to make a decision on this, and sometimes it's a part of the data engineering workflow, and sometimes it's a part of a software workflow that is, you know, still informed by a data engineering workflow because
the software has to produce correct data. So it's all kind of there's a lot of gray area between the data engineering and the softlow the software engineering, is what I'm saying. So I've really been liking that lately because yeah, because again I can give like people who need actual like web interfaces, I can give them pretty easily web interfases. But at the same time, it's all just really integrated into the workflow, and I can automate as much as
can be automated. So normally it will look like, you know, we have like three steps, and then there will be some point where human has to approve something. The human will get like a yes no kind of form, and then that feeds back to airflow and we'll either pick off the rest of the workflow or cancel it, depending on how that how that ends up going. If I'm not doing anything that's complicated, though, I tend to just use githab actions because it usually is just like Make builds, Make tests.
And the problem with the problem with starting with whatever it's easy because it's not complicated, is six months later it's complicated, and then you're married to that tool. But that's the problem with like make files versus basscripts versus Pearl or Python or something like that, like, oh, it's just simple, I'll just use Make tests, and then six months later you have the six thousand line make file and nobody can understand it. And I should have done this in Python.
I don't think I'm quite ready to give up my Make files, Jonathan.
I don't think that's I like me, although I like Make, but I have done some really nasty make stuff before, stuff I would these days never do again. I think, I mean, I have no problem. Yeah, I'm pretty sure Make is touring complete and it should not be.
Files from like cold Dead Hands.
No.
No, I think there's a really good lesson hidden in there. Though. One of the keys I think to making successful pipelines is to wrap all of your individual steps up into a smaller command and then just have the pipeline call that command. So when you look at the pipeline, it's like it does these five things, and now those five things might represent a bunch of other smaller tasks, but I think that's still more easily understood by someone coming
in to work on it. Then if you have a CICD pipeline that has six hundred individual steps in.
It, well, that's what I like about air flows that right out the gate you get a picture of the directed a syclick graph, so you know step one, step two depends upon step one, which if that's successful, it goes here. If it's not successful, it goes here. Like it gives you a picture of that right in the dashboard so you can see it, and then you can actually click on each individual part and it like colors it based on whether or not it was successful and
this kind of stuff. So I just find it much more intuitive for like a person to deal with rather than a any of the other CICD work cloths. I mean, I'll use them because they're there and they're free, but like, if I'm going to build anything complicated, most of the time these days, I just go build with an airpluck.
I think get lab does a fairly good job that of visualizing the pipeline and the you know how how to build or how the pipeline is going to run, which steps are dependent and which one failed?
Oh my goal trial. Okay, I don't actually think your lab is probably one of the ones I haven't only used.
One thing I really like about get lab is that it so easy to start your own runners. I run some private projects that aren't eligible for their free, open source unlimited minutes or whatever, and so every month I get this thing. If you here, I don't know how many minutes or four hundred minutes or whatever, upgrade now
for like twelve dollars or whatever it is. I'm like, no, I just I have a Hetzner dot d account for I think three dollars a month, and if run a get lab runnerund there and I connect to that, and so for three bucks a month, I have unlimited minutes. It's super easy to do that. I haven't logged into that server for probably two years's probably been hacked by now,
I don't know it's mining block chain. I think get hub Actions is going to be adding support for the maybe they have already added the ability to run your own runners too, but I mean that's also really nice if you have special hardware you need to be using, if you need a GPU to run your tests or something, or you want to run on an ARM system or Raspberry Pie or something like that, that's something that that's
the reason we didn't discuss at the beginning. If you have special needs like that, you're going to be limited in which CIC tools you can use. Like try to see I believe offers Linux and MAAC. Maybe they do Windows now I'm not sure. But if you need to run your code against Windows on Windows servers or a Raspberry Pie or whatever you're gonna have, you're gonna be
limited and the choices you have. So that's one nice thing about being able to run your own runners that get love gives you, and I think ge hub actions either does or soon will. You can set up your own runners to access your hardware encryption devices, or your MPEG encoders or whatever random kind of custom stuff you might need, So that that's something to think about too.
Yeah, specifically, if you're building iOS apps, I've dealt with that quite a bit, and that's a huge pain because it's got to be done on a Mac. So you're either using a Mac that you have physical access to as a runner, or there are some third party services that will integrate with your CICD and do the build for you, but all the ones I'm aware of are are relatively expensive.
Yeah.
I got into like three D modeling a little bit is my quarantine hobby, and that immediately made me think, like, how do video games like when people make video games, right, because they're the point is is that you're supposed to be able to release them on like all the platforms now right, Like you see a video game, it's not just like on PlayStation or Nintendo or whatever. It's it's on like everything. It's on. It's for games, it's for
the switch, it's for all of them. So I always kind of wonder, like, well, how do they do their testing? I kind of find a whole lot on it. It seems like every it's still like a very closely guarded, secreted video games. I did see a little bit that like Unity uses AWS because AWS have actual Mac like instances, Like you can run Windows instances and you can run Mac instances. But for the rest of them, I don't know, just build and hope it runs and people can install it.
If you listen to the comments from the gamers. Then, yeah, that's the exact strategy. Build it and let your customers figure it out.
Yes, your customers need the acceptance testing. That's my business model too. You know what.
I haven't done. That's a really good point. I haven't done any work in the game industry. But yeah, there's a lot of compiling for different platforms that happens there. And I don't know what to compile time or to build time for your average game is.
I don't know. Let's get pretty involved, Like I feel like, just like so really small scenes and like small little games and unreal and that's it's backed by C plus plus, so you actually have to go through and compile everything, and even for just like a you know, something really small, it can take a while.
Yeah, any game you download these days is it seems like it's a minimum of five gigs. A lot of that's video assets, I would assume, So I don't know if those are involved in the compiling process or if you can compile your video assets once and then just compile the run time for each specific platform. I don't know how that works.
Next week on adventures and game development.
Right, let's see who we know that works in that industry that we can get on the show.
No, there was a couple of plug ins and like they weren't they weren't very well developed for different platforms, and I know, like an f C plus plus that I was like, huh, maybe this should be my new calling. Just go and then fix all the platforms and set up the CICD and make plugins that actually compile to the different the different platforms and sell them on the marketplace. And what am I doing all this data science stuff for? Anyways?
And then I figured out, you know, very quickly, that it wasn't that simple hopes and dreams, most as most things tend to be, It was not that simple. Yeah, I think if you have like specific HERD, if you have specific hardware or specific security considerations, you should really like look into your choice and not be nearly as asual is I tend to be with like, well this
one looks good today. You know, it's not the action that I need this morning, So we'll use that, you know, maybe actually go through and do your research and think about it a little bit and see which one kind of or if any of them support the different platforms that you need.
Unless you have a coupon because we know if you have a coupone, you're using it.
Oh so you know that's one thing with thought. I signed up for the free prile of Spacelift and they immediately like they contacted me on like day, They got me in a Slack connect group with them. They will like call us if you're not call us, but you know, like message us if we need anything. And I was like, oh, well, this is almost as good as a coupon. So do we have any like good projects for people starting off and see ICD? I think you were talking about that a little bit early, Terronic.
Yeah, I'm actually gonna do a course probably starting on April about this. I'm going to walk people through, so stay tuned. I'll give them more details as it approaches. But the concept for my course is I intend to walk people through publishing an app. Maybe it maybe you build a PHP app or or something, or if you haven't built one, we get to see this work press
or react some react to do NBC or something like that. Yeah. Yes, to take a simple app that uses the database and deploy it to Kubernetes using CICD with the sort of review environment that will talk about, so you can every time you create a ProQuest, it'll pop up this temporary environment you can play around with, do your testing on, and then when you merge it will teare it down to it away. So I think that's that's a really good way to start. Pick a simple app if you've
written one. If you haven't written one, you can just download, like I said, to do NBC or something like that, some sort of test app or work press or whatever, PHP, my ad Man, anything like that, anything that's an app that at a web or basis of a place to start, and just deploy it somewhere and deploy automatically. I don't mean like type cupit, cuddle whatever, you'll do that in the process, but get it automated so that when whenever you commit, you run your tests, and when you hit
merge at automatical ploys. Which tool you use is less important than just getting that process done. So I'll probably do the course of get lab to CEI, but I'm going to try to keep it as generic as possible and simple Bash commands so that anybody who doesn't want to use a good lab can apply the same knowledge to GitHub actions or to genkins or whatever other tool they want.
Yeah, I would agree that's. Yeah, the act of taking something from code to deployed is a huge learning experience for somebody interested in getting getting into DevOps. And another key point that you mentioned there is if you don't know how to write code, or if you haven't built an application, that's not a blocker because in the software engineering world, like one of the most common things for learning a new language is to create a to do apps.
So if you go to GitHub and search for to do apps, you're going to find thousands of them that you can download that meet those criteria of having a web user interface and a database back end and just use that exactly.
Yeah. I would also add try to get at least familiar with the idea of matrix builds, which is where you want to kind of build things with different options, even if it's kind of you know, you're sort of artificially putting it in there. So an example of that would be you take your you take your to do app and you install it sent hosts, Ubuntu an Alpine, and you do that through doctor containers or however you're going to do that. But that would be three variants
of the same package. And I'm sure that you know like things will come off along the way there and then you'll kind of you'll kind of learn about that process as well.
That's a really good thing. If you're building a shared library and you don't know who's going to be using it, you know you want to make sure it works on Mac, Windows and Linux, for example, and you want to make sure it works on three different versions of Linux, then that's exactly the time when those matrixes are matrices are are called for.
Oh well, does anybody else have anything to add or should we just go to picks?
Just do some pics every week?
One of us, all right, Donald, who wants to go for astronomers? Not me?
I'm not.
I've got I'm ready this week. So I'll stall for time and share way more details about my picks than what I should to give Jonathan an extra few minutes. So I've got two picks this week. First one is a movie called The Blacksmith and the Devil. It's on Netflix, and its super cool movie about a surprise no school over alert here. It's about a blacksmith and he captures this demon that he thinks is responsible for all the trauma and turmoil in his life. And he's got this
demon captured and he tortures him. But then there's this really cool plot twist at the end that has you going, oh, dude, right on, let's go. And so I won't tell you any more than that to keep from ruining the suspense. But it's a really cool movie. The Blacksmith and the Devil really well done. Only on Netflix as far as I know, but I only watch about maybe two or three movies a year, and this was one of them. So it was it was cool. It was a good couple of are spent. The other thing for my pick
this week is these eye drops called Acuity. So like as the as the old man in the group, I feel obligated to tell you all that as you get older, your eyesight's going to go bad and you need like a close yeah, Like you need a close circle of friends who will call you out so when you're heading into the store with your sunglasses on top of your head and your eyeglasses on your face, that they stop you and go, no, no, no, we don't do that around here. So you need that group of friends in
your life. But otherwise you can get these eye drops that just came out in fall of twenty twenty one. If you're like me, whenever you got old and your eye your eye drop, eyesight for reading went to hell. These eye drops are specifically made for that. So you put these eye drops in and then for like the next four hours, my vision is like it was ten years ago. And so it beats wearing glasses, or more importantly, it beats trying to figure out where I left my glasses.
So those are my two picks for the week. Do you ever wonder where you left the eye drops so far? No, I've been using the eye drops for about a week now, so we'll see what the long term impact of that is. But right now, I just keep them in the bathroom and whenever I get up and get ready for work, I'll drop them in, and then around lunchtime I'll go and put the next set in because they only last for about four hours.
I haven't pick ready, now go for it. So I just finished reading a book. It's an old book, but it's a classic book. It's a good book. It's been made into two movies. That's how old it is. It's been around long enough to make two movies out of it. That's all quiet on the Western Front and It's a fictionalized story of a German soldier during World War One, and it really just tells the story of more the feeling of combat in World War One and the trenches
more than like a military story like this. There's no story conquest or whatever. It's here's what it was like to live in the trenches and deal with death and with the fear of death and not enough food and that sort of stuff. So it's a really good book. Obviously, it's I mean, probably everybody's heard of it. You don't want to read or listen to the book. Wat's the movie. There was one that came out in the twenties, I think black and white, and then it was remade again
in the nineteen seventies. So I me recommended nice cool.
Well, I'm going to pick The Wheel of Time. It is one of my favorite book series. I reread it every couple of years, and I wanted rereading it again because I tried to watch the Amazon series of The Wheel of Time and I couldn't quite get through that. But I just decided to go back to the source material and go back to the books reread those. It
really is like one of my favorite series. There's a couple there in the middle that you could probably skip and like, you know, you would be fine in terms of plotline and things happening and all that kind of stuff. Just get the cliff notes. But I don't know, they're really great. They're one of my favorite series. Go for It.
So there's that, and then I think on tech pics, I've been playing with this program called Hissora, which is like as it's one of these web frameworks, you like throw it on top of the database and then it
just kind of spins up all your APIs. But one kind of thing is that it has subscriptions and real time events, and another nice thing is you can also pull in like additional APIs, so if you have if you have like a series of micro services, you could use to have to kind of tie them all together and then it could handle, you know, throwing your authentication tokens and stuff like that around. So I've just been playing a little bit with that. It's been fun. So's
it's a good program. I recommend it. Go see it. I think it's got lots of stars on GitHub. And yeah, that's it for me. All right, guys, Well that's a wrap. Thanks and talk to you next week, all right, See you guys,