Speaker 1: 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.
Speaker 2: And technically I'm laughing with you, not at you, because
you were laughing too.
Speaker 1: It's okay. I only felt a little bit put on
the spot.
Speaker 3: I'll forgive you some day to be fair.
Speaker 2: I did say okay, let's go and then hit record.
Speaker 3: 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?
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: Yet I tend to agree it's.
Speaker 1: Always a trade off. Yeah, everything like that is a
trade off.
Speaker 2: The best CICD is the one that you already have installed.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: No, No, I thought really hard and decided not to
do it.
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: You can on a Commodore sixty four?
Speaker 3: 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?
Speaker 1: 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.
Speaker 3: So if you don't care about security.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: 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?
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 1: That is cool, though Human in the loop, well, I
like it, yeah, And.
Speaker 2: 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.
Speaker 3: Have you used any others or is that really the
main one you used?
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: I don't think I'm quite ready to give up my
Make files, Jonathan.
Speaker 3: 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.
Speaker 1: Files from like cold Dead Hands.
Speaker 3: No.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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?
Speaker 1: Oh my goal trial. Okay, I don't actually think your
lab is probably one of the ones I haven't only used.
Speaker 3: 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.
Speaker 2: 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.
Speaker 3: Yeah.
Speaker 1: 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.
Speaker 2: 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.
Speaker 1: Yes, your customers need the acceptance testing. That's my business
model too. You know what.
Speaker 2: 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.
Speaker 1: 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.
Speaker 2: 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.
Speaker 3: Next week on adventures and game development.
Speaker 2: Right, let's see who we know that works in that
industry that we can get on the show.
Speaker 1: 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.
Speaker 2: Unless you have a coupon because we know if you
have a coupone, you're using it.
Speaker 1: 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.
Speaker 3: 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.
Speaker 2: 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.
Speaker 1: 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.
Speaker 3: 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.
Speaker 1: Oh well, does anybody else have anything to add or
should we just go to picks?
Speaker 3: Just do some pics every week?
Speaker 1: One of us, all right, Donald, who wants to go
for astronomers? Not me?
Speaker 3: I'm not.
Speaker 2: 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.
Speaker 3: 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.
Speaker 1: 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,