every single day development teams are building and updating their code and at some point they
need to take that code and push it out to the final product we all know this is happening but
did you ever wonder how this happens the way that this happens in a very practical sense
is through what's called releases and on this video we're going to talk about how that happens
specifically on github which is one of the most popular platforms let's take a look at a couple
of examples this first one here is dbt labs it's the dbt code which if you follow this channel you
know this is the tool that i am a huge fan of and that many companies are using and if you
look over here on the right we see releases we can see there's 87 releases that they've done
here's another example this is airbite this is an open source data extract and transform tool over
here they have 83 releases they're on an alpha version over here third here's apache airflow
and theirs is actually a little bit different if we were to open this we can see the way they've
done this is their version 1.20 the first thing you may be wondering or that we should touch on
is what do these numbers mean and all of this isn't just made up what it's based on
is what's called semantic versioning this is used to come up with your versioning number that
zero point or one point whatever and the way it works is like this major dot minor dot patch
and what do those mean an easy way to identify the impact that this release this version is
going to have on your code if you're changing the major version you're going from zero to one or one
to two you're making changes that are incompatible api changes it's meaning what you've just released
is not going to work on a previous version version two is not going to be completely compatible
with version 1 and so on and so forth minor is when you're making a change that
you're adding new functionality in a backwards compatible manner meaning 0.2 should be compatible
with 0.1 you're adding a new feature but the foundation of it isn't completely breaking
it's not a completely different structure of the api or whatever you're working with
and then the last part patch is when you're making backwards compatible bug fixes instead
of adding a functionality you're fixing something that may have broke the main idea here is to be
able to iterate through your code release versions and do it in a way that everybody understands
what's going on the last thing i'll point out here is you may be something like a pre-release and
that's where you might see something like alpha it's indicating to the public or whoever wants to
use this that it's not completely production ready you can use it but just be a little weary of it if
we look back at airbite they're on 0.30.16 alpha so you can kind of get a sense for where this is
in its development cycle along with the versioning number are tags and if we look in the github
documentation it says releases are based on git tags which mark a specific point in your history
and they don't have to be the exact same thing as your release version if you look up here v 1.508
is the tag the release version is 1.580 so you have that v in there it's technically different
but it should match up and that's that's how it's going to work and if you want to learn more about
git tagging there's a whole bunch of documentation here and i'll link this in the description before
we go in and try to create our own release i want to go back to what we're seeing
here what does this mean essentially when you create a release you're packaging up
all of the code in your project at a given time and saying here are the files and everything
that you need to know about this in this case here if we go to this version of dbt
they're adding some descriptions you can add links to whatever you want and if we go to the
bottom they do a great job of documenting this down here is assets and here is the zipped up
version of your source code this is going to be everything about this code if we open this up we
can see that exact version of the release that was shipped and if you were to go to a previous
one you could see the assets here as well and do the exact same thing and see the code as it was
at that release here's the tag as well here's the latest commit you can compare between tags so you
can see the differences between one release or another you can see it's incrementing here that
means there was likely a bug fix between these you can also link to specific merge requests this is a
huge reason why version controlling in something like github is so effective and so important
because you can organize all of this stuff and link to it at a specific time and everyone can
see exactly what it is now we understand how this works how can we create one i have my own version
of a dbt project this is by no means a production ready project it's a mishmash of all sorts of
things that i've been doing on this channel but let's just see how would we create a release here
right here we can see i don't have any let's go ahead and create new release first thing it's
going to say is choose a tag and we don't have one we could either create a new tag on the fly
or we can create a new tag on publish i'll just create one right now we'll call this v
0.1.0 we'll start with zero because this is the first major version you start at zero one because
this is the first edition and zero because it's not a bug fix this is the first one that we're
going to create i'll go ahead and create that tag this tag will be created from the target you could
do it on a specific branch i'll do master and over here we can see some tagging suggestions as well
and here's a link to that semantic version and call this my first release and here we
can do markup whatever we want just like we did before now if you have some attachments you want
to add you can add this here we can drag and drop we could say if this is a pre-release
meaning that it's not production ready i'll click this just because it's not and let's say publish
release and here it is we're done here we can see it's marked as a pre-release here's the title
and here are the assets so if we were to open this up just like before we can see all of our code
that we have in here anyone can see it and here's the latest commit here's our tag there you have it
that's how you create a release and get that going one more thing i want to point out before we wrap
this up is the ability to automate this process you saw what we did we manually went through some
of those steps and created this release if you've watched the video on github actions you'll know
that there are a lot of custom things you can do one of which is creating a release
now i will point out here that this particular one that i'm landing on
is archived by the owner meaning it's not actively being managed but this is just an example it's an
actions a github action to create a release and you can see it allows you to put in information
name release body if it's a pre-release all these things and create a workflow that will
do this process for you this is something you can do to automate your deployment process if you know
all the steps you want to take you can create a workflow and at a push of a button it'll create
the release and some of those manual steps are removed from that process again this one
in particular is no longer active but there are several other ones that are maintained so
click into these and see the same kind of things that they're doing and incorporate them in your
project and we can see hey this one even has 288 releases wow that'll do it for this video if you
have any questions on this let me know thanks for watching and we'll see you at the next one