We've evolved from, if it builds, ship it, to continuous integration, where every check-in
is automatically verified by something like Travis CI.
Taking that further, some people today are using continuous delivery.
This means once a check-in is validated by the CI system, it's deployed automatically.
There are many moving parts in these processes.
On this episode, you'll meet Chris Medina, who has put together a world-class CI CD system.
And he's here to share how he did it and what tools and libraries are involved.
This is Talk Python to Me, episode 166, recorded June 11th, 2018.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is sponsored by Linode and Rollbar.
Please check out what they're offering during their segments.
It really helps support the show.
Chris, welcome to Talk Python.
Hi.
How's it going?
Glad to be here.
It's going great.
Yeah, I'm happy to have you here.
It feels like we were just hanging out in Cleveland just a little while ago, right?
Just a little bit ago.
Yeah, everybody's scattered back to where they came from.
And it's sad that PyCon is over.
But that was really fun to spend some time together there.
Yeah, for sure.
It was great to meet the PyBytes guys, too.
I hadn't met them before.
So that was pretty cool.
Yeah, they traveled quite far to get there.
From both sides of the globe.
So, yeah, I mean, PyCon is such a special place.
And PyCon US seems to be where the most gravity is.
I know EuroPython is also large.
But I feel like that PyCon US is probably the biggest.
Just get the sense that I get.
Anyway, I think just, you know, recommend that people next year, if they didn't get a chance
to go, definitely go.
Like, wouldn't you say?
Did you have a good time?
Yeah, definitely.
So, like, I started doing PyCon maybe three years ago now.
And it's definitely been a lot more interesting to so much stuff from so many different people
doing so many different things with the language.
Because Python has such a wide usage.
It's just great to just be out there and just see what everybody's doing at.
And I like just hanging out in the expo hall and just kind of just talking to everybody.
So you're like, oh, what do you do with Python?
And definitely the open sessions, people don't quite, you know, understand how cool that is
versus, you know, your average conference where everything is just kind of like pre-configured
for you.
Yeah, definitely.
Both you and I ran some open sessions, right?
That's true.
Yep.
Yeah.
What were yours on?
I did two.
I did one on just blogging and stuff, folks that are creators for Python.
And I did one on virtual reality, augmented reality, and to see how, you know, experiences
with people and Python and that type of stuff with those environments.
Yeah, that's pretty awesome.
So now that you're back to doing what you do day to day, maybe we could get your story
and your background.
Like, tell us how you got into programming in Python and what you do day to day.
My story is more like a classic story.
Dad grew up doing software.
He had a consulting business.
There's stories of two-year-old Chris sitting in his lap typing in the keyboard somehow.
Not that any of that was intelligible, obviously.
But yeah, so he started stuff with old IBM systems.
Like, you know, monochrome monitor, eight and a half inch floppy integrated keyboard,
no hard drive things.
No hard drive.
That still blows my mind that computers came with no hard drives.
Yeah.
So I remember the first time I actually got an idea of what, like, software was.
It's because my dad wrote something for me to sit in front of his computer and learn the
times tables.
And it was just a short little program, but I could go into the program and fiddle with it.
So I was really young for that.
And I still remember it.
It was pretty cool.
It was an IBM system 23.
Nice.
Would it, like, randomly pick, like, two numbers, multiple, you know, and ask you what the answer
was and say you got it right or wrong, basically?
Pretty much.
That's pretty nice.
Like interactive flashcards, basically.
I remember doing a data entry forum back in the days where you can't slurp anything in
from any APIs or anything like that, right?
Somebody would just hand deliver an invoice and you had to type it into the computer.
When computers were not actually connected to anything, they were just there on a desk.
How weird, right?
Right.
Exactly.
So some of the first stuff I did was system 360 basic.
My hello world was like a menu for, like, opening an invoicing app or something like that.
Back when you had to type line numbers and make sure you left enough room between them in
case you needed to add more lines before.
Yeah, that's right.
Like, if people don't know this, that used to be a big deal.
So it used to say, you know, 10 would be like a line number and you would put a command and
then 20, you'd put like another.
And the reason it didn't go one, two, three is you might have to do 11, 12, and 13 someday
and you don't have to rewrite the whole program.
It's so insane that you had to explicitly call out the line numbers.
But I guess with like the go to navigate, like a sort of branching mechanism, you had to say
go to this line.
So it had to be really clear what line that was.
Yep.
And then we added go sub.
Oh, man.
I was advanced concepts right there.
Huh?
That was amazing.
All right.
So you started there.
Like, did you go and get a computer science degree?
So I did computer engineering.
I actually was like, well, I kind of halfway understand at least some of the software stuff.
So let me see what all the software is built on.
And I went off and figured out how to do hardware.
So I did computer hardware, computer architecture, that type of stuff.
And, you know, from there I went into IBM, which was the first guys that hired me.
So I spent many, many years with IBM doing systems tests.
Were you doing hardware stuff for IBM?
I was on the side of we developed a new server.
It would come into our organization and we ran validation on it.
So before I made it out to the customer, we would go and check a bunch of things.
Like it was gigantic organization, tens of thousands of tests that would execute.
So we had like a small piece of that that had like integration with more on the integration
level of the server with the firmware and the hardware.
So I'd have to do hardware tools that I'd have to code and say like some sort of what is today
embedded systems, right?
All the way up to like high level software tools to, you know, maybe interface with that stuff
or even business apps too, which was the biggest thing I wound up doing,
which was kind of a management system for keeping track of all our test organizations and stuff,
including status reporting, test execution, procedures, all that type of stuff.
That sounds pretty interesting.
I don't know a whole lot about the hardware side of computers.
I mean, obviously I have some concepts, but like I couldn't, you know, design RAM or anything like that.
Right.
It's just, that's always, that's sort of like where, you know, the Darby Dragons sort of aspect
of programming is for me.
Like I have a conceptual idea of it and I don't know how close that is to reality.
So it's, it's pretty cool that you kind of get a bridge to that world.
Yeah.
So some of the most interesting, so why some of this stuff is important too,
is because you get to understand a little more, some of the more recent security things called
Rowhammer, if you've heard about that.
Oh yeah.
Tell people what Rowhammer is.
So Rowhammer is a way of essentially kind of hacking your machine to run code by accessing
certain parts of memory at certain speeds such that you would make an adjacent memory cell
have the data that you wanted or the code that you wanted to execute.
And then maybe that adjacent memory cell is the one that's in like the privileged memory.
I see.
That's so tricky.
Does it use like a cache hits and misses and stuff like that?
Are there the prefetch stuff or where, where does that come from?
So this is actually winds up in your actual, so it's a, it's a general problem with DDR3 in
general.
So anything that has a DRAM from DDR3, you could do that in as long as the refresh rates, you
know, memory, your processor kind of controls how often memory is refreshed.
So it would go in and blank out, you know, whatever charge is accumulated.
So if your refresh rates are, if you wait a long time between refreshing, you have a larger
window in which you can get in and make those changes.
So, so it'll actually happen on your DIMMs.
Oh, wow.
These are crazy ideas.
Like we're seeing a couple of these, right?
So there's a row hammer, there's spectra, there's meltdown.
I mean, these are like not even software problems, right?
These are down in the chips.
Yeah.
So then the other, the other ones you mentioned are down at the processor level.
And a lot of things, a lot of those are because optimizations to trying and execute instructions
faster.
And the way, the way that processor pipelines work, you want to prefetch some information.
So I know some, I know one of them, I don't remember which one, which one was what, but I
know one of them was more related to branch prediction.
So if you, if you're going through code and you have an if then else kind of thing, it'll
prefetch both sides of your if, whether it meets the condition or it doesn't.
And then you can play with that a little bit and have it prefetch some memory information
that, or data that, you know, it shouldn't have because it's at such a low level, stuff
like that.
Yeah.
It's crazy.
Yeah.
It's going to be interesting.
I think we'll probably see more of those types of things, but it, you know, it really gets
scary when you mix that with cloud computing and we're going to talk about cloud computing
a lot, actually.
So maybe start with, yeah, maybe start with what you do day to day, let people know what
you're working on.
So I'm part of a small group of folks that worked for a company called Nimble Storage that was
acquired by Hewlett Packard Enterprises last year.
And Nimble makes storage arrays.
So as in external enclosures where you have a bunch of hard drives that you access through
iSCSI or Fiber Channel.
And these are for like data centers, right?
These are not like NAS for your home, are they?
Right.
These are built for data centers.
So these are expensive things that have a performance, you know, way higher performance that you get
something out of a consumer product.
And so they have a bunch of systems management and stuff around that as well.
And a bunch of guarantees in terms of data savings due to deduplication or compression and
things like that.
Enterprise class features, snapshotting and things of that nature.
Okay.
So nice.
So if you run like a hundred VMs, like most of the OS is probably the same across all of
them.
You just need that one copy of those files.
Right.
So we do instant snapshots.
So if you, if you have a virtual machine, so one of the use cases is say you have like
a database in a virtual machine with like, say your database in it, and that's all contained
in a couple volumes of which you can group together.
You can go in and say snapshot that and it happens like instantly and then spit off a
new VM based off of that, those volumes you just made over there.
And now you have a copy of your data essentially.
And it keeps track of the diffs.
So it's kind of like a, if you, if you bring it back to the software world, it feels a little
bit like you were playing with Git really.
And, or Docker where you have like a special commits, which have your data.
And then you have the diffs of your data into the next set of commits kind of thing.
So when you do your snapshots and your clones, instead of having a, an entire duplicate of
all of the data, you only have the difference that you write afterwards.
So that's also pretty helpful.
So those are the arrays that we make.
And so one of the things that we're kind of experimenting with cloud stuff, we decided
to go off and built what is cloud volumes.
So the product is called HPE Cloud Volumes.
We can, and the purpose is if you have a, an Azure or an AWS virtual machine and you want
to tie it to some of our storage arrays, you can go to the website and request volume of
certain size and other characteristics along with it and configure it so you can plug it into
your, your VM.
That's pretty interesting.
So tell me why would I like pick that say, instead of just like creating a volume in AWS
or Azure in their mechanism, right?
Right.
So one of the main things is that you can go cross cloud.
So you could have your volume that you made with say your Mongo data or something.
And, you know, it's attached to your AWS, but you know, if you're running a super critical
application and say your AWS region goes down, you can just clone that volume and attach it
to Azure and you can use it on Azure side of the world.
The other thing you get out of it is we can do a higher IOPS when talking, when, when doing
the IOPS is a measure of how many storage operations, IO operations you do on your drives over the
array.
Then you can get out of a regular EBS.
And as far as I understand the instance snapshots as well, I forget if EBS does instance snapshots
or not.
I don't think they do.
So you also get that ability.
There's also extra stuff that we provide for our actual physical enclosure customers.
So if you own one of our physical arrays, you can actually replicate your data up into the
cloud through our service.
And you don't have to worry about the ingress costs through AWS or Azure.
So we provide a way of seeding information out to say different regions and things like that
as well.
Oh, that's pretty interesting.
Cause yeah, that can get pricey real quick.
Yes, it can.
Yep.
Yes, definitely.
I know a little bit about bandwidth charges and whatnot.
I think last month I paid $600 in AWS bandwidth.
Oh, geez, man.
You're getting lots of downloads.
Woo.
No, these are good problems to have, but that's a lot of bandwidth.
This portion of Talk Python to me is brought to you by Linode.
Are you looking for bulletproof hosting that's fast, simple, and incredibly affordable?
Look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe.
They're going to run a lot of data center near you.
Whether you want to run your Python web app, host a private Git server, or file server,
you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network, 24-7 friendly
support, even on holidays, and a seven-day money-back guarantee.
Do you need a little help with your infrastructure?
They even offer professional services to help you get started with architecture, migrations,
and more.
Get a dedicated server for free for the next four months.
Just visit talkpython.fm/Linode.
Another thing you do is you spend a little time writing some fairly popular articles on
your blog.
I know because Brian and I end up covering them often on Python Bytes.
Yeah, no, I appreciate that too.
So I don't know if it's like a chicken before the egg thing.
It's like something comes up a little bit, but then you guys post it up, and then it gets
a lot more reads.
But yeah, so I have tryacceptpass.org, and we do the posts include a bunch of stuff, usually
things I play with.
Most of the articles that get the most views usually are how-tos.
I try to do a lot on async.io stuff because I'm trying to do more async.io, and that is not
an easy concept as it is today in Python.
Yeah, the work that you're doing there is really nice because I feel like that's a lot of
areas where there's really not very much coverage.
I'm definitely planning on writing a course on async.io because I feel like either people
are just, they know about it and they're confused, or like, ah, it's too hard, or they just don't
even know, right?
They're like, I'm switching to Go because Go has better async than Python, but you don't
understand.
It does too.
You're just not using it.
I understand it's not as integrated into the web frameworks as it should be, but still.
Great.
But even that's changing now, so it's getting pretty good.
And so I just want to try to keep playing with that and post that up there.
And I also do a couple of things just on general engineering and software and a little bit of
testing since I spent so many years in tests.
I got this series going on called Practicality Beats Purity, mostly about that part of Python
and how to, one thing sounds great, but how good is it really when you implement it kind
of thing.
Right.
Like one of the popular articles you had was microservices versus monoliths and all
the interesting trade-offs you make there.
So we'll definitely dig into those, but I kind of want to focus on the whole reason we started
talking about having you on the show, which is the continuous delivery you're doing around
your work you're doing in HPE, right?
And so maybe let's just start with what is continuous delivery.
Like I know there's continuous integration and that's like something watches my repository
and does some sort of build verification on check-in.
So what's continuous delivery?
How's that typically work?
So continuous delivery expands on top of the continuous integration concept and say that
build I just built, I want to do everything that I need to do to that build to make it deployable
to production and have it available to be deployed to production, if not already deployed in production
automatically.
And so the idea is to set up your, be able to deliver code into production as quickly
as possible in a way that that's maintainable while still having a set of status checks around
that, that you can, that makes your job easier.
Right.
Okay.
So maybe the Holy grail is like, I've got a GitHub repository and it has different branches.
So maybe a branch is called production and a branch is called staging.
And if you commit into staging it, you know, after some delay of the builds and creation
of the servers and whatnot, there is now a new staging server or services based on top
of that where you did nothing but wait a little bit.
And that's kind of how we have our stuff set up.
We have two branches and every, everything that's on our production stuff.
Production branch is things that have gone already out to production.
So everything there is a known working build that we can deliver to a customer.
And we have our, we actually use the master branch for all our staging stuff, which is things
that are fully tested or all the, we've guaranteed, we can guarantee that all the basic functions
are tested.
And the whole thing is completely built into a deliverable that we can actually go and put
out in staging.
And so as we go through our, our pull request cycle flow, GitHub flow type thing, get flow,
we can automatically put the build up in our staging environment.
Right.
Okay.
So you guys use the get flow style of work.
Now this is really common in open source.
Like some random outside person wants to make a contribution to a project.
They don't have right privileges.
So they'll fork the repository, make the change, do a PR back, and then the people can review
and accept it.
But some organizations, sounds like you guys, do that even for yourself on your own projects
as a way of sort of like formalizing it, right?
Right.
So we use GitHub enterprise internally, but things like GitLab also have a similar concept for
this.
It's just called differently.
So we have brand, our master and production branches are protected branches.
And the only way to get in there is to go through a pull request merge.
So we don't necessarily require the developer to have a separate, like a forked.
repo.
They just have permissions to push their own branch into our main repo.
So once they push their branch and they open a pull request, we have a whole set of automation
systems in place which receive the webhooks for the pull request and kick off automated builds,
our style checking, linting, and all of the testing that goes around that pull request.
And so you can even in GitHub say, I require the following statuses because the pull request
object in GitHub has the concept of statuses.
As you run those webhooks, the code that kicks off from those webhooks, the status is reported
straight back into that pull request.
And in GitHub, you can say, well, if all of these have passed, only then is your pull
request valid to be merged into whatever branch it is that you want to go.
Yeah, that's a really awesome feature.
And to me, it sounds like this is a really nice way to sort of pre-vet what would be standard
code review, right?
Like instead of going, well, you've done your work.
Now let's review it and see if it's good.
It's going to be like it's on the verge of being merged.
And then you've already had all the tests done and everything is good.
You push the button.
And when that happens, it automatically deploys with no further work as well.
So it's just like that one gate, right?
Right.
Once all our tests are done and once the review is approved, we click our button.
We do some other niceties around it.
We kind of squash every right, our merge commit a little bit so that it's useful.
And we press the button.
Right.
Maybe talk about that a little bit because, you know, Git can like if I'm going to do, excuse
me, I'll create a branch, I'll do like 20 commits, a bunch of little tiny ones.
And then eventually I'm going to create a PR from that.
You might want that to not look like 20 small operations, but one holistic one, right?
Right.
So we try to follow a system where we abstract more as we go down the production side.
So we have as much detail as possible on the branch that the developer put their things
together in.
So all the commits on that branch are going to be the itty bitty things.
Started to work on this feature, went to lunch, came back.
Oh, didn't work.
Trying it again.
Yeah.
You know, there's like a bunch, there's a bunch of really funny commits that go into that.
And then you say, okay, so I'm ready.
So here's what I'm going to take all that group of 20 commits and merge it as one commit
up into my master branch.
And so I go back and clean all that stuff up and say, these are the features that are
going in.
These are the issues that are getting closed because GitHub has all that automation.
And for us, you can say closes hashtag issue number and automatically closes the issue for
me.
And then when I press a squash and merge button, all that stuff gets squashed and you only get
one bubble in your master branch with the summarized changes.
Yeah, that's really awesome.
And of course, you can go back to the other branch and see it, right?
And see all the details.
Yep.
Yeah, that's really nice.
I wonder how many people actually use that GitHub automation around like interacting with
issues.
I use that all the time, even just for myself, you know, hashtag some ID of an issue or PR
and say, this is related to that.
And it's really nice to just get those automatic links in there.
Yep.
And like, I'm very opinionated on issues.
So I love the way that GitHub does issues, not in the UI or anything like that, just like
the idea of it's an issue.
It has a title, it has a description, some comments in it, and some tags, some labels,
right?
I don't need anything more than that.
Everything else can be described with labels.
Like Jira to you feels like you're swimming in too many, like UI soup.
Yes.
And so I've used like half a dozen different issue trackers.
At the moment, the one we use internally actually is Jira.
So, you know, we have the usual GitHub versus Jira thing.
So we actually wound up writing a kind of a bridge to help us out, follow our business
logic in Jira as we do stuff on GitHub.
So we also listen for issue webhooks and update Jiras for us automatically.
But this way I can go open an issue in two seconds by typing it into GitHub.
And then all the stuff just kind of that goes into Jira gets all rolled into place as it
should be.
Oh, that's a really, really awesome way.
Like, I don't really want to work in Jira.
So I'm just going to automate working in Jira like my robot will.
Yeah.
And you got to be careful with that stuff because then you'll wind up maintaining it.
But right.
Nice.
But yeah.
So once our pull request is actually merged, more of our webhooks also say, oh, there was
this pull request that got merged into master.
So that means we need to deploy code.
So we open a new pull request to go to production.
And so that's what we call our deploy pull request.
And so that one does a little bit of the different thing where it actually builds.
So our deliverables are container images.
Docker containers, right?
Because our service runs in using Docker and AWS container, elastic container services.
So just to step back on that a little bit.
So a lot of people get confused.
Docker containers is one thing, but there's really two concepts.
There's the image.
And then there's the instantiation of that image, which is your actual container, right?
So when I go and say, I want an image of my REST API, that means I have the file system in
place.
So that when I say Docker run, I can instantiate a version of that image and execute my code inside
that environment.
So we deliver our two different images, one for our web service or web UI and one for our core stuff.
So all of the orchestration that we have to do in order to make our service work, which involves cloud
orchestration with AWS and Azure, some third party data center orchestration, switch management,
array configuration, and then all resource allocation algorithms, user management, all that stuff.
That's all kind of bundled into one container image.
And we run it with different environment variables to have it perform different functions.
So we have a microservices architecture, but with two images.
The way we manage the way that AWS works, when you have the container service in it, you define
a service like my core REST API service.
And I say, I want this to run several tasks or one task.
And I want, I wanted to run this container, but I want this image tagged in such way.
So for example, in our repository for that, the REST API backend, when we deploy an image, we push up the code
and then we say, okay, we're ready to move to staging.
So we tag it with staging latest.
So then I can go to AWS and my deployment activation work of make this image.
Now the valid one in this environment is just stop the containers.
And then AWS will automatically restart them.
And when they start to come back up, they say, oh, there's a new staging latest image.
Let me download that and use that one.
I see.
That's really cool.
So basically the AWS container service just knows I'm going to run out of this, this get repository
with this tag.
And I just always look for that.
If necessary, rebuild it.
Right.
A Docker image.
Yeah, yeah, yeah.
So, and right.
So everything just builds off of that.
And it's really helpful also because if you broke things for one reason or another, all you
have to do is move your staging latest tag back to your previous one and restart the containers.
Go now, undo it, undo it.
Yep.
That's all you got to do.
You don't have to worry about anything else because you know that was working code and you're
back in time.
Now, there's other.
That's really nice.
Complexities when it comes to database migrations and things like that.
But 90% of the time, you don't have to worry about it.
Right.
Okay.
That's really nice because like it's one thing to roll the code back, but you're potentially
making infrastructure changes and OS changes at that level as well.
And the ability to go, oh no, just put everything in the back of, put it back like it was.
It was working.
It's pretty cool.
Yeah.
Because like once, so the code underwent all the testing and all that worked and the
container image that we used to build that code.
And I'll get a little bit into that in a minute is, it's slightly different than the one I actually
wind up putting in staging because it has more stuff in it to maintain the test infrastructure
or be able to get to the test infrastructure.
The one that actually makes it up into staging, which is equal to the one in production at that
point also has a bunch of other things like an NGINX configuration that's a bit different
or a micro WSGI config along with it.
So I can easily like mess that up.
And it's only a problem I see when I go to deploy it.
Right.
I just, today I would have liked to have something like this.
I mean, I have multiple like staging and production servers for my various things.
And one of them, I got an indication there was an upgrade for IDNA, I think some, which
is some low level dependency on my, my system.
And then there's requests.
And so I upgraded the low level thing and said, oh no, requests forces, you know, to use an
older version of that.
So guess what?
Your site won't even start.
It's just dead.
But luckily it was like running on, like I had taken that one out of the load balancer and
like, oh my goodness.
But I had to do a lot more work than just move the tag back.
Right.
It was like, all right, well now how do I unravel this?
How do I make it know that it's supposed to install the right one and all that kind of stuff.
So it, yeah, it sounds, I can definitely see the advantage here.
And that actually happens quite often with a bunch of things, not just your Python libraries
that you have to worry about and their interactions, but also your Docker images.
So what happened to us in the past couple of weeks while we were going through testing, like
in the middle of I'm tests are passing and then all of a sudden everything's failing, what's
going on?
Like a couple minutes.
We actually hit where whoever maintains the base Python Docker image that we depend on
iterated on it.
They changed it.
Oh boy.
Yeah.
And the new one, and obviously we can go back to the older one, but at this point we
wanted to move with a new one.
The newer one changed the base.
I think it moved the major version.
So all the app packages and stuff like that had updated.
So I needed to use different, different names to pull some stuff.
So that was fun.
Yeah, that's fun.
And if you do that on the real machine in production while it's running, not so good.
Yeah.
Not so good.
Right.
That's why all this stuff is in place.
That's right.
This portion of Talk Python to Me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
relying on users to report errors, digging through log files, trying to debug issues, or getting
millions of alerts just flooding your inbox and ruining your day.
With Rollbar's full stack error monitoring, you get the context, insight, and control you
need to find and fix bugs faster.
Adding Rollbar to your Python app is as easy as pip install Rollbar.
You can start tracking production errors and deployments in eight minutes or less.
Are you considering self-hosting tools for security or compliance reasons?
Then you should really check out Rollbar's compliant SaaS option.
Get advanced security features and meet compliance without the hassle of self-hosting, including
HIPAA, ISO 27001, Privacy Shield, and more.
They'd love to give you a demo.
Give Rollbar a try today.
Go to talkpython.fm/Rollbar and check them out.
One question I did have while you're describing what you're up to, and we talked about the
GitHub hooks like hashtag closes, hashtag one, two, three, or whatever.
Is there a way to make that happen only when it merges into the main branch?
Or does that PR commit itself trigger the closing of that issue?
Yes, I understand what you're asking.
Yes, it only happens when you do the merge.
Oh, really?
Okay.
Because I type it in my commits all the time.
Interesting.
Okay.
Well, that's awesome.
Yeah.
Very, very nice.
All right.
So maybe one of the things, I think maybe the most interesting thing to cover is like,
we've now set the stage of what you're building, but all the various pieces, there's so many
cool little libraries and packages and things involved in the act of building this whole pipeline
that you've created.
So do you want to walk us through that?
In order to run all the testing, we have a Docker swarm internally on premises in our data
center where we orchestrate all of this stuff.
So I have a container running that is my webhook receiver.
And I built that one, that REST endpoint for that using a hug.
Hug is a Python 3 REST API, kind of like Flask, but it's a bit smaller and a little more expressive
because it uses annotations when you're defining your functions to define the input type of your
parameters from your REST API.
It also automatically generates documentation.
Yeah, that's cool.
Hug is really interesting in that it's like one of these REST only frameworks.
It's not built from as far as I understand it, mostly for building web applications,
but more for building web services.
And there's a...
Yeah, there's a host of these that are really amazing at sort of leveraging Python 3.
So hug is definitely in there, which is super cool.
API star.
And API star.
Yeah.
That's the new one I'm playing with because API star fully supports asyncio.
So I can have an async function and have API star serve it up.
That's awesome.
Yeah.
I can just await in the function.
And in the meantime, it'll go off and do other things.
It's pretty cool.
How about hug?
Does it do asyncio?
Do you know?
I don't think so.
Last I checked, it did not.
But it was...
I think it was able to handle it better because it was all Python 3.
Yeah, it's definitely all Python 3, which is cool.
And if you look at the performance, Hug is built on a framework called Falcon.
Falcon, yes.
Which is also another cool web framework that probably no one else has heard...
Not many people have heard of.
But I had the guys building Falcon on my show.
And it's like a really low level, high performance...
It is.
...web framework.
And then Hug is actually built on top of Falcon,
which is pretty cool.
But they're definitely...
Both of those are like right near the absolute top of performance in terms of request per second on some random piece of hardware.
So, yeah, pretty cool.
I find that a lot of things like Django, Pyramid, or Flask, right?
These things have been along for a while.
So they have a bunch of things they do for you.
And the higher level of abstraction that you get out of a framework, which is what you want from a framework, usually.
The more careful you got to be with performance, because in order to give you that abstraction, they needed to put you through a number of other levels, especially...
Usually, function calls, which in Python are a little bit expensive.
They're surprisingly expensive, actually.
Yes.
Yes, they are.
Yeah.
And so, for example, one thing that Hug says, and I think this is partly coming through the Falcon side of things, is it's compiled with Cython to basically get much higher performance, which is a pretty cool aspect as well.
Yep, yep.
Okay, so you've got this, and this is one of the really important things about this Docker stuff, is it's awesome to have your database in a Docker container and your web framework and then your backend services.
But they all need to know, okay, where are you?
We just all got rebuilt.
Where are you now?
Who are you, right?
How do I find my backend?
Right?
So that's the role of this thing that you built.
Right.
So that receiver, the web receiver also can communicate with the Docker swarm using Docker Pi.
And then orchestrate, oh, I need to build a new container.
I need you to start a new container.
I need to build a new image.
I need you to start a new container with this existing or newly built image.
So, for example, one of the things we do is when the web hook comes in, we go in and do use requests to go up to GitHub, grab some information on the repository, search for a file.
That kind of works kind of like how Travis CI does.
We have a YAML that says, oh, here to set up for testing.
Here's your install instructions.
The actual tests are these things.
And there's a bunch of other settings we can do.
So one of the things in there might say, well, I want all these tests to run in parallel.
So that means I got to orchestrate getting the container built, the container image built off of the repository the way that the instructions say they're supposed to be done.
Then taking that and committing that new image to an internal registry that we have and then telling our Docker swarm to start five to six parallel images to go and execute tests based off of that new image.
And then those tests all have to require resources of their own.
So we have another infrastructure piece, which is a resource manager that all it does is it sits there and receives, waits for a WebSocket.
So I can, in order to pull, essentially check out a resource, I open a WebSocket connection and I say, oh, I want this type of resource.
And while that WebSocket connection is open, I have a reservation on that resource.
So that makes it so that I can write tests and not worry about releasing the resources when they fail.
Oh, that's pretty interesting because when the thing goes away, it just, it, because it breaks.
Yeah.
Socket closes.
Boom.
It's all done.
Huh.
I didn't realize, I thought you were just doing push notifications.
I didn't realize the WebSocket like session had such an important role.
That's pretty cool.
Yep.
So we do that.
And so for that, I used Autobom before, which is something I used inside Sophie, one of my open source modules.
But I recently moved it to WebSockets.
It's a module called WebSockets.
It's a lot more, it's built around AsyncIO a lot better, more Pythonic using Async4 and AsyncWith.
So it makes it a lot easier to interact with in a coroutine kind of way.
Yeah.
Interesting.
So your test might just do AsyncWith WebSocket connection and then do its stuff?
Something like that.
So the test will, the test will, the receiver will do an Async4 around the WebSocket, around receiving something in a WebSocket.
And so that's on the server side.
On the client side, we just open the socket and do, I think on the client side is an AsyncWith where you just sit there and just kind of wait for messages.
Interesting.
That's pretty awesome.
So then another thing that you do after the test pass, then you build your artifacts, right?
Like your packages.
And you use proper Python packaging as part of this, right?
My two main deliverables are container images, but I also have a, those are built on top of a bunch of other repositories that I have.
Two or three of those repositories are, their deliverables are actual Python packages, which are internal.
And we use an internal Python package index for that, which we later migrated to a tool called Artifactory.
I had never heard about Artifactory.
This is a thing by JFrog.
Yep, it's by JFrog.
It is, oh my goodness.
That is one serious piece of like enterprise software management software there.
Yeah, it's a lot of stuff.
A lot of stuff.
Python package indexes, NPM indexes, whatever those are called, just NFS, Docker registries.
And then you can mirror.
So if you have stuff in the outside world, you can mirror those and you can have it automatically push things for you.
And you can, you can add like tags and properties to things.
It's, it's quite complex.
It has a REST API too, to get to it.
It's pretty interesting.
Yeah, it's really interesting.
Their website has like a bunch of cool little animations.
It just makes you, it kind of draws you in.
So to me, it looks like you've taken, you guys in general have taken a lot of the awesome stuff from the public open source and maybe sort of made your own private version of it.
So you've got, you know, GitHub Enterprise.
You've got like a private PyPI server, private Docker repositories, all sorts of stuff, registries.
Yep.
It just makes the whole thing easier to work with because you have, you have an existing ecosystem that can work with all of this.
You don't have to build your own modules to talk to them.
Yeah.
Super cool.
I'd never heard of Artifactory, but it definitely looks like, like worth checking out.
It's no small piece of software as far as I can tell.
It looks like a big, a big thing that does a whole bunch of stuff, but it definitely looks like it.
It's pretty cool.
Yeah.
And it comes with its own complexities.
So if you want, if you just want an internal package index, really, there's a bunch of existing things already you can use, or you could just build your own.
I built one with Hug before Artifactory.
It's just a web server.
Right.
It's just a web server and a couple of interactions.
It's not super complicated, but yeah.
Pretty cool.
And so we talked a little bit about some of what happens next.
You have your GitHub hooks and your PRs and all that kind of stuff.
What else is involved?
So you have your Hug service that you've talked about.
That's pretty awesome.
You used PyDocker, which you mentioned in passing there.
DockerPy, sorry.
Which is just pip install Docker, right?
Yes.
Nice.
Pip install Docker.
Okay.
So if you wanted your Python app to, say, orchestrate creating new containers or spinning them up, that would be what you use?
Right.
And it's got two client layers.
One is like a lot lower level, which is an API client kind of thing.
I think they call it API.
I forget what they call it.
And then there's one which is like the Docker client.
So the Docker client operates more at an object level.
So you can say, so you point it to where your Docker, your main Docker master is of your swarm.
And you can just do .images, .lists, .create, stuff like that.
Same thing for .containers.
And then with the swarm in general, things get pretty complicated when you go out to swarm or Kubernetes, mostly because things are your containers that are managed by the swarm are not really containers.
They're services.
And it all makes perfect sense if you're running, say, a web service.
And you say, I want a web service that needs to always be up and I want two instances of it.
So you run one service with two tasks, each one of this type of container.
But for us that are actually creating essentially one container or two containers individually to run every time, we have to make a new service for it.
So there's a lot of layers there that complicate things a little bit.
But it's very easy to manage with Docker Pi because it's all kind of built by the Docker guys.
Yeah.
Okay.
That's really, really cool.
And then another thing that you use is something called ChatOps.
What is ChatOps?
Is that like something for DevOps?
Sure.
When our deploy PR is complete, that means it built a container image and it pushed that image out to our Amazon container registry.
So then we need to, we could automate this, but I still want to have some manual checks in place.
So what we did was we have a chat system and just made a bot.
And I can tell the bot, hey, I want this image to be my staging image.
Go do it.
And then the bot will go in and tag that image with staging latest and it'll go in and stop all my containers in AWS and which will automatically restart and essentially do my flip over from to a new version.
That's awesome.
Now, ChatOps in general is kind of like a concept of being able to run, to manage a bunch of services or deliverables or code or whatever you want to do over a chat system using a bot, essentially.
Yeah.
That's a pretty cool idea.
I mean, we saw Kelsey Hightower's thing at the 2017.
Yeah, it was 2017 PyCon where he got basically Google's voice assistant to do his Kubernetes stuff, right?
Yep.
So I was kind of laughing through his presentation a little bit because I was like, yep, that's what I do, except I can't talk to it.
But, you know, not through voice, right?
Well, you're not far away from getting some Google Home or some Alexa.
Yeah.
You could use some of the Alexa stuff going.
And my, sorry if everyone's Alexa is going off, mine is as well now.
The Amazon assistant, let's call it that.
There's a Python one called Calliope we were just looking at today.
And there's another one, I forget the name, that's also pretty famous in the Python world.
We were just laughing at it this morning saying that we should hook all our stuff up together and just say, hey, deploy to staging.
Hey, restart our stuff.
There's some pretty easy ways to do it, actually.
Yeah.
Just some random dude walks into the cubes and just kind of kills all our stuff.
Deploy production.
No, no, no, no.
Yeah, that's pretty awesome.
Another tool that I don't think I've heard of that was really impressive to me is Locus.
Yes.
Yeah, tell us about that.
Like, use pytest for your standard level, your automated testing.
But Locus is more on the performance side, right?
That's right.
So, Locus, the idea of Locus is to test web services.
So, you can write tasks in the forms of scripts or actions that represent users of your service.
And you can have, like, all set of kind of like setup and teardown and type of stuff, kind of like your regular type of test environment.
But then Locus can manage that over a large amount of virtual machines to go off and test your API and then come back and tell you, well, you managed to receive these many requests per second in this endpoint and these many in that endpoint.
And this one was rate limited at this point.
And this one was, you know, errored out when you did this thing.
And so, you get a report.
That's really cool.
So, you've got, like, all the different parts of your site.
And it shows you, here's the number of requests in a big grid.
Like, this URL got this number of requests with this many failures.
And, you know, average response time is this.
And, yeah, it's super cool.
Like, one of the big problems with the load testing is actually it can be at least getting enough pressure on your web server, right?
Like, if you just do that over, say, your broadband connection at home on your laptop, like, maybe the limit is your outbound network or something, right?
Something like that.
Whereas, like, if you could put it on 100 VMs, spin them all up and, like, you know, turn those loose in a slowly way.
Like, that's awesome, right?
Yeah.
You can have a different amount of virtual machines and it just kind of orchestrates all of them for you.
You just got to have Locus installed on them and the scripts that they got to run.
But, yeah.
Yeah, this is looking super cool.
I definitely would like to look more into it.
So, yeah, it says define user behavior with Python code and swarm your system with millions of simultaneous users.
You know, when tools like this exist, I'm just blown away when there are websites that fail so badly when they get a lot of traffic.
You know, like, I understand there's some limit where it's like, okay, it just is not going to take more.
But that limit should be many thousands, not a couple hundred, right?
Right.
And so, another thing we did, so we used Locus to figure out where we might break.
And then what I do is there's in our Docker image, whenever that actually gets executed into a container, there's a few instructions that go in and replace environment variables in our Nginx configuration.
So, I can go in and tweak the request per second.
So, I do it at the Nginx level so I never hit the Python code.
So, if I know I'm going to break at whatever, I can put in a limit at 8 or whatever on my...
And then it just queues in Nginx until...
Correct.
...until Microwezky's done it.
So, you can configure Nginx to do that per IP address or just in general and what error codes to return, all that stuff.
Oh, that's awesome.
So, a couple of other tools that are at play here are some of your projects.
One is Sophie and one is Corv.
So, Sophie falls to a pretty interesting realm of Python, I would say.
Yeah.
Maybe tell people what Sophie is.
Some people talk a lot about user interfaces and Python.
I don't know any of those.
Oh, yeah.
Actually, I think it was after one of your very first, like a long time ago, conversations about user interfaces and stuff.
And I was like, oh, you know, I'm pretty sure this is exactly what I was thinking.
I've built so many, you know, Bootstrap-based quick interfaces with like some just jQuery default stuff.
I don't want to write that anymore.
I want to just write it in Python.
Yeah.
So, what I did is essentially...
It's a module that lets you do that where I kind of wrapped the widgets that you'd get out of Bootstrap, the HTML kind of library to help put that together.
But it evolved because the way I do it is through WebSockets and AsyncIO.
So, in the back end, you can kick off a web page that loads off a basic JavaScript library that you only have to write once, which tells that web page how to interact with Sophie.
And you run a Python web server, WebSocket server, which is Sophie, that actually sends commands out to the web page.
So, you open up a website and all of your interaction and eventing can go all the way back to your Python code and you can react on that and come back out to the UI.
And after that evolution, I realized that Sophie is actually really a WebSocket protocol to help you do all of this and kind of like library to help you do all of this.
Because you can just drop in and replace other ways of doing these conversations between client and the server.
And so, what I did after that was I went to a game engine, Unity 3D, and dropped in a WebSocket client written in C#.
So, now I can, from Python, spawn game objects and things like that in Unity.
That's pretty awesome.
So, it's a little, a tiny bit like Electron.js type apps where there's like a Python backend.
It's some sort of web front end, at least the first incarnation of it.
It's also deployable kind of like that if you want as well.
But you can also do it.
So, the original idea was to go down a desktop application type thing, in which case you would want to build it like that, like an Electron.js thing where you distribute Chromium, the browser that Chrome is based on, which is completely open source as your front end.
But you can just deploy the backend by itself onto like some service in a Docker swarm, which is what we do.
And just open up a web page and talk to it.
Yeah, nice.
And your other project, Corv, is about sort of skipping the whole REST API entirely, right?
And using actually SSH?
So, in the process, over the years, working on different services, right?
You always want to have, there's always the customer facing one.
But then you always want some data or something you want to have in some admin mode for.
So, it's always a risk to put those admin endpoints in the customer facing one.
Because if they're there, somebody's going to fiddle around and bump into them.
And then you've got to worry about security and all that.
Right.
It just takes one forgotten security check and all sorts of badness happens.
Right.
Especially when those checks are usually decorators around Python functions, which you could forget to put in.
Right?
Yeah.
So, the idea is, instead of using HTTP, use SSH.
And there's, the first time I came up with this was when I ran into Async SSH, which is the base library for this.
Because I wanted an async way of doing SSH calls.
And they let you do this.
So, I let SSH take care of the authentication.
You've got to have your client cert the allowed clients, known hosts as well on both, you know, your known hosts on your client and your acceptable public keys for your client on the server.
And so, SSH handles your authentication.
And then after that, you open a TCP socket over SSH and just send information back and forth.
I just wrapped it in JSON and kind of used kind of HTTP-ish REST-like mechanisms for, like, get, store, update, and delete.
So, I do that as my admin interface.
It's only accessible to me.
But even if I break, even if I mess it up and it somehow exposes the ports out to the internet, it's still SSH.
So, you still need the proper keys to get in.
Yeah.
That's really awesome.
I think that's quite a cool idea.
Like, I have certain things where you can only get to them through SSH.
You can't access them or interact with them, you know, without that.
And this is kind of like, instead of just exposing, like, tunneling that through or something, you're like, no, let's just make that the API network layer.
Yeah.
Exchange layer.
Both of those are async.
So, you can just have it kick off long-running things.
Doesn't matter.
You'll get a callback when it's done.
Kind of thing.
Yeah.
Really cool.
Let's see.
Another couple of things that were really interesting that you're using.
One is PyAutoGUI.
And that's from Al Swagger.
What's that?
These are kind of more of an experimentation thing.
So, we have pytest to execute all of our tests, which is great.
We use Selenium for a few things.
And then we use some other JavaScript node-specific runners for the WebUI stuff as well.
But you just, like, browser compatibility is always going to be an issue.
We want to try to do something more at the...
We ran into a couple of issues where you say, you open this thing in Firefox, but if you open it in Chrome, this one little piece of it is kind of wonky.
It's larger than it should be or it's off the screen and things like that.
Yeah.
So, PyAutoGUI lets you...
Does a lot of stuff.
It's about automating your OS through GUI things.
Move the mouse here.
Click on this.
Type this from the keyboard and things like that.
Now, it also helps you take screenshots.
So, one of the things that I was thinking was we could put something together that says, open browser, type this into location bar, load web page, type username, type password, click login.
Right?
And then take a screenshot of the result and then use OpenCV to compare that screenshot to an already existing screenshot that I should have and maybe find the next button I have to click on.
And if that button is not on the screen, then error, move on.
Kind of way.
The advantage of using the OpenCV stuff is you can have a confidence level on it.
So, if things are off, you'll know.
That's totally cool.
Yeah.
There's a project by a friend of mine named Llewellyn Falco called Approval Tests.
And it will do something similar, basically.
It will go and instead of having a whole bunch of tests, it just says, here's the output.
Is that good or bad?
You say, yeah, this is good.
And then it records that.
And then unless that output changes.
Oh, sure.
Right?
And it could do that.
I think it does that with pictures as well.
Right?
So, you could screenshot something and go, this is the verified version.
If this changes, I need to check it out.
Otherwise, just keep running the tests and saying they pass.
Cool.
Yeah.
So, something like that is what we wanted to do.
Yeah.
That sounds really cool.
And you were talking about using OpenCV as well, huh?
That's cool.
And I actually tried out a few different things and OpenCV wound up being the faster one.
Yeah.
Awesome.
Cool.
All right.
There's just so many little interesting tools and steps along this whole process that I think a lot of organizations are trying to get to, right?
Like I said at the beginning, right?
I check in, I merge a PR, I wait, magic appears on the other side, right?
With zero downtime.
But it sounds like you guys have really got it pretty nearly there.
That's awesome.
So, was it worth it?
Oh, for me, it is, right?
I mean, you have to, but you have to step back.
You have to do your engineering work behind it, right?
Don't just do it because everybody's doing it kind of thing.
If we have a service, right?
So, it is in our best interest to make it as fast and as easy as possible to release a fix out to the customer.
Yeah.
And the last thing you want to do is like try to release a fix and then take the whole thing down and make it worse.
Exactly.
So, the way to go through all of this is you have to step back.
You have to look at your process.
You have to, it's a lot of pieces and a lot of moving parts.
So, you have to say what checks do I need at which point in time of my delivery flow does it make sense to check what?
So, if I say all these tests need to pass here, that means I've guaranteed this basic function is working.
These tests pass here, that means my infrastructure is working, et cetera, et cetera.
Right.
And it also depends on the quality of your test, right?
Like you need to know that if the tests pass, pushing to production without further question is okay, right?
Whereas if you only test a few things and maybe they don't test that well, like if a lot of stuff slips through, then this isn't so helpful, right?
It's got to be a good net.
Right.
And we made the decision early on to put, to invest into that because, you know, we think it's going to bear fruit for us and it has been very useful.
We very, very seldomly have a really broken function into staging.
And when we do, the first thing to fix is not the function.
It's the test to make sure that you can't push again with it broken.
Yeah.
That's a really good point.
It's like, why did this get through?
There's actually a problem in the continuous delivery system that it got this far.
Now let's fix that, right?
That's awesome.
Yeah.
And take advantage of the situation that you're in, which is you have a real failure, not something that you thought you might have.
You have a real one.
So make sure that your tests fail when you have a real failure and then go fix the code to make sure that it passes.
That's awesome.
I think that's really great advice.
All right.
I want to take just a moment, let you maybe list off some of your popular articles that you've written, but don't want to take too much time since we're running out of that.
The most viewed article over time from the blog has been Threaded Asynchronous Magic and How to Wield It, which is pretty much about an intro into AsyncIO and what you can do with it.
Yeah, it's a really good one.
Just how to manage tasks and stuff like that.
The one that's like most read, as in like the most time people have spent going through all the details was the Python Ate My GUI, which was the starter article for making Sophie and kind of the state of GUIs in Python.
And the most recent one I have, which is now no longer true, the most recent one is about GDPR.
And the implications of the European, the new European regulation on, for software developers.
But the one before that, which was the one in my list was Practicality Beats Purity about microservices and monoliths, which we talked a little bit about already.
Yeah, people should check that out if they're considering one or the other.
And there's a lot of interesting trade-offs that you highlight there.
All right.
So if this was a few weeks ago, I might ask you a little more about the GDPR and get your thoughts on that.
But there's something bigger to talk about.
So you talked about using GitHub Enterprise.
Like I'm super invested in GitHub.
I just checked like right now, the time of recording, I have 134 repositories in GitHub.
That's a lot.
And many of those are private ones, like supporting my various things, but a lot of them are public as well.
So the big news, like last week, was that Microsoft acquired GitHub.
Yes.
What was your first thought?
Oh boy.
That was my first thought.
Yeah.
I'm not a Microsoft fan, but I am willing to admit that they have a different direction, which I like, which is way more embracing of open source.
They are the world's greatest, biggest open source contributor today.
Which is like, think about where we are, just that you said that.
Like, that's crazy.
Yep.
They have incorporated Linux into Windows, sort of.
They have contributed a significant amount of work to Docker.
And GitHub, or Git itself, actually.
The Git virtual file system.
And Git, yes, with the Git virtual file system, which was a huge contribution, especially for folks doing large single repository code bases.
So that's, for me, that's a good direction.
Unfortunately, the track record so far hasn't been all that great, even with their most recent acquisitions.
The most common one that I hear and that I have problems with is Skype and where that wound up with.
But some folks also complain about how LinkedIn is going.
I don't know.
So I don't know.
Internally, there was a lot of outcry from the community.
But equally, there's a lot of Microsoft developers that are like, well, but we at Microsoft love GitHub just as much as you guys do.
And I genuinely believe that.
It's not about whether the folks contributing to the code like it or not or want to keep it going or not.
It's the fact that now you've concentrated the majority of open source projects in a business that has its own languages, its own platforms, its own software, which you could maybe wind up getting biases for.
And once it's there, it's just going to be more complicated.
There's also questions about IP that people brought up.
I don't know how much that's a thing.
But, you know, technically, everybody had access to all those repos anyway.
But I guess now they get access to all the private ones, too.
So I don't know.
Yeah.
So a couple of thoughts.
Yeah, I definitely sort of felt similar to what you're saying.
Like, I don't think Microsoft has any sort of bad intentions towards GitHub.
I think they do.
Right.
I think they do really love it.
They're really invested in it.
However, you know, they could fumble, fumble it and just make it not so nice.
Right.
I don't think they would like intentionally shut it down or do something to make it less good.
But they certainly could try to make it better and make it worse.
That is a thing that could happen.
The IP part is pretty interesting.
What really surprised me is there's an article called, it was on Ars Technica.
That's one of my favorite places to read this kind of stuff because the comments are great.
It says, everyone complaining about Microsoft buying GitHub needs to offer a better solution.
And they really went through point by point, like how GitHub was actually in pretty big trouble.
Yeah.
And at some point, this is almost like, would you rather not have GitHub or have a GitHub that Microsoft owns?
Rather than, well, I want GitHub to be this free thing.
Like to me, the biggest negative here is, it's just consolidation.
Right.
Like there was this sort of independent place where open source could go be its thing.
And everybody was on sort of equal footing.
And now it's been consolidated into one of the big five tech companies.
And that just, that's just different and not necessarily better.
But after reading this, this Ars Technica article, I felt much better about it because I didn't realize the alternative was as bad as it.
It could be.
But I mostly don't like the fact that it's just consolidating further in the whole tech space.
I think that is the main concern.
I agree.
I think after going through this, I think it becomes a bit more obvious that we kind of, I think I said this over Twitter, we kind of need like a Mozilla software foundation of open source repositories kind of thing.
Yeah.
Like an independent body that's somehow funded that whose sole purpose is to just, you know, you put stuff up there and it's going to stay there and, you know, we'll keep it up kind of thing.
And that would alleviate the concerns a bit.
It would.
I think on the positive side, I think, you know, Microsoft has done a good job with Xamarin, right?
And that was open source sort of, you know, they, I think that that's stronger now than it has been as part of them taking it over.
So there's one, you know, check for maybe the win, win box, you know, Microsoft's part of the Linux foundation.
And they're like, there's signs that this is going to go well.
There's like you said, Skype example.
So there's also signs where it might not go so well.
So I think it's, it's up in the air.
My concern is the two things like it could just get fumbled and messed up.
But the fact that they're running GitHub as an independent organization, it's really good.
The fact that Nate, the guy that was one of the co-founders of Xamarin is running, going to be the CEO of GitHub, where apparently they were struggling to get a CEO at all.
There's like a big problem there.
So anyway, it's, I think it's, it's pretty interesting.
Fingers crossed for a positive result.
Yeah.
And from the business perspective as well, you know, Microsoft, I'm sure it makes perfect sense for them.
They just spent all this time into the Git virtual file system stuff and they just moved all their stuff over to that.
So they want to secure a future for that.
Right.
And this is their, this is their way of doing that.
Yeah.
I guess the other thing is that sort of gives me sort of a positive outlook, I guess, is at least the way I've seen it these days.
It's like, if you want to understand what Microsoft is doing or why they're doing it, the, the answer is Azure.
And then you've got to figure out what the question is.
Like, obviously it's for Azure, Azure, Azure.
They're just trying to grow Azure.
Like they could just care less about windows or to some degree office, right?
Like they see like the, the new lock-in is the cloud.
And how do we go be part of that?
And you know, all the different technologies run there.
So I think that that's going to put some pressure to keep it more fair handed rather than say it's only .NET or it's only windows or any of these sort of pressures that you kind of hinted at at the beginning.
Yep.
Agreed.
All right.
Well, I guess we'll leave it there.
We could go, we could have a whole show on the thoughts of the Git application.
Maybe I will at some point.
At first I was like, oh boy, this is probably going to get messed up somehow.
But after spending a week doing more research, I'm kind of like, well, it looked kind of like it was necessary and it's probably the least bad outcome that we're going to get.
So, you know, fingers crossed.
Yeah, for sure.
Cool.
All right.
So let me hit you with the last two questions before you get out of here, Chris.
So notable PyPI package.
We covered a bunch actually.
The two that I would bring out out of the whole list, which since we're kind of talking about async stuff as well as async SSH.
Forget about Parameco.
Async SSH does it better.
And there's, and the WebSockets module, which it's pretty good if you're doing anything with WebSockets.
Nice.
And so final call to action, people want to bring continuous delivery into their whole workflow, their life, their team.
How do they get started?
The first thing to do is to, we kind of touched on it a little bit earlier, is step back, analyze what benefits you get out of it and what problems you're trying to solve.
And then slowly go through it and put something in place where, you know, my end result is going to be X, a delivered package of this here.
And I need to guarantee that it works in pieces at different steps of the way.
And figure out the effort to make that happen.
If the effort is really, really, really, really, really large, then maybe it's not worth it for you.
Cool.
Well, I really appreciate you coming and sharing what you guys are up to because you definitely have it pretty dialed in.
Yeah.
Yeah, no problem.
Glad to be here.
It's always fun to have these conversations.
Yeah.
Thanks, Chris.
This has been another episode of Talk Python to Me.
Our guest has been Chris Medina.
And this episode is brought to you by Linode and Rollbar.
Linode is bulletproof hosting for whatever you're building with Python.
Get four months free at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
Want to level up your Python?
If you're just getting started, try my Python jumpstart by building 10 apps or our brand new 100 days of code in Python.
And if you're interested in more than one course, be sure to check out the Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I really appreciate it.