Control your GitHub releases with GitVersion and GitReleaseManager

okay so if everyone's ready I guess we'll just get started so hopefully you're all here for this talk so my name is Gary park then from Scotland came down yesterday I work for a small company called Dai up in Scotland the agenda for today is to have a brief discussion about a few topics that lead up to the overall topic so the overall topic is controlling and organizing your github releases but in order to do that we sort of have to discuss a couple of other things such as semantic versioning support semantic versioning is a branching strategy potentially using different writing strategies throughout your codebase and leading up to that we then start talking about the actual tools but you're here to talk about or I'm getting wet rather get version and then ultimately get released manager and what we're going to do is we're going to have a booth discussion all that and then at the end we're gonna have a demo hopefully at the end if everything works the way it's expected to to show how you can use those tools to ultimately control your get up losers that you need to but one of the fundamental principles of what I'm discussing here is really traceability what I want to be able to do within my development cycle is I want to know that that bet code I've shipped on to this production server what is it where did it come from and what version number does it have what issues pull requests bugs features went into that release and ultimately who was responsible for that so that the fundamental principle of going through all of this is that traceability in getting that information at your fingertips from you really when you need it okay and format up today it's a couple slides and then some demonstrations feel free to ask any questions that you have to wait to the end and just throw your hand up and we'll have a discussion about it so the first one or tackle is what is the month of versioning just runs versioning is quite a loaded topic you can you can really have an entire session on what semantic versioning is and we're not doing that today so what you see certain website what is semantic versioning semantic versioning is simple in quotes set of rules environments that dictate how you version numbers are assigned and incremented now I like to say that's a loaded statement and we're not going to go into the details of that but ultimately if what that means is or what that translates to is this simple set of rules and the rules break down to this if you've got a three-part version number your major your mind in your patch then you only bump the major version if you've done some sort of breaking incompatible API change across versions of the application you'd want to bump that version number for the major version number so to communicate to the subscribers of that application or that assembly or library that something has changed fundamentally and their ultimate ly going to need to change their code in order to use it you would pop the minor version number if you've added new functionality that hasn't in any way broken any backward compatibility changes okay and you'd want the patch if all you've done is if you private sum again backward compatible bug fixes to the code base so what that translates to is you're without doing anything else you are conveying to your consumers some information about the application that they're taking a dependency on so this doesn't always get here - and they're open in the open in the wild out there in the wild but that is the premise of Samantha Samantha versioning what we're not going to talk about is how you know when to do all of these things because again that's another topic all in itself but because you can have to have touched on these topics at least in order to start that process going so some examples of a semantic version is that it's as simple as that that's a very very simple tamaki burgeoning zero point one point zero that's ultimately the first version number that your application should start it in my opinion you'll see some that start with zero zero one but what we just said is the rules is that you should use either one when you're shipping bug fixes how can you ship a bug fix on 0:01 release because you have actually both X and X so it's in my mind that is the first version number that you protect the door and at this point it's fair game because what you're saying is you haven't met the first major release so your 1.0.0 release at your first major release and at that point you then have breaking changes atop your API if your public facing API when you're in the 0 1 0 2 0 3 again you are in this realm your your public API hasn't been defined so your prior to that initial release so that goes forward so they hand out your first release your 1.0.0 and then another example would be that this one so someone has made 13 bug fixes on the third release that really some piece new piece of functionality but what happens with semantic versioning is it starts to get a little bit more complicated you can add a little bit more information onto the actual version number so what you're just saying on this one is that this is a build that came to unstable its intended to not be consumed by the public it's you maybe have that as an internal build and it's a third one of those SUVs okay so I've done another example and then things get skip nuts and you have a version number that looks like that right so this is this to me is what you always want your version numbers to be and I'll explain that a little bit because what this is telling me is that this is the third build of my unstable 0.20 release that came from the develop branch and that is the share of the commit in my repository that build came from so again this idea of traceability is that that build I can go right back to the exact commit that that came from and my github repository or my I'm saying github and I might get repository and I know exactly where that bill came from now what you don't obviously want to do is display that on your website and say that this is the this is the build they're the version number that you're releasing what I do with that is I can have two version numbers for my deployed applications one is this the basic semantic version and one is the full semantic version number now I stamp onto this and the supportive so that is the whistle stop to our open semantic versioning is and I say it's a loaded topic and but that's as far as we're going to discuss about that today okay so when you start talking about semantic versioning you kind of have to start in my mind again this is my opinion you sort of have to start talking about branching strategies as well because ultimately in order to be able to fit it facilitate the release of patched versions and incremental version release incremental feature releases you have to have some sort of ranching strategy to know again what's going at the door if all you're doing is committing on to a single branch in your repository then again tracing exactly what's going out the door becomes difficult because it's one linear progression of circle development so again unfortunately this is a loaded topic and branching strategies both all how they're good in they're bad bad things about them so what I'm going to discuss just now is two of the the main branding strategies that right there there are others but we'll just have a very quick overview of what those are and what we can do and how they facilitate us going forward so the first one you might have heard of is just a standard github flow it's a this is of the two branching strategies that we discussed it's the simpler one take from what take from that what you brought you well but the way get up flow starts is you have this name the balance right that's the line across the top and what you ultimately do is the first thing you do is you create a feature or you're adding a bug or you're fixing above you create a branch that's the first thing you do you create a branch and that's where your work happens and then you add some commits on to that branch actually committing the new feature or fixing the bug and all that work taps happens off a name trunk then what you can do is you open a pull request you can then at that point have a number of code reviews from various people within your team fix any issues that come up send that through your testing infrastructure however that looks like and then ultimately you would deploy that onto somewhere to test the date and then that gets merged back into the main branch so if you can imagine you've got four or five developers within your team that there will be four or five active branches at any one time they're all working in isolation and then what they're doing is emerging and then updating their own branches as with new features merge into the main trunk okay so it's a reason a simple workflow most if not all source control systems would have this functionality and it's kind of a it's common I like to say it's commonplace these commonplace for me I don't know is everyone using branches and distinct portions of the dock good ok so we're not okay so it's commonplace everywhere let's make that extension so that's the first branching strategy that you may have heard of the second one is git flow so let's let's preface this a little bit this is the more complicated one it's it's more complicated but once you kind of grok it in my mind is the better one but again that's eluded loaded the topic so we won't go into the depths of that but what that the main difference between github flow and git flow is their github flow as a single main branch of development where the feature branches off of that where it's git flow has two main active branches the develop branch in the master branch develop the develop branch and git flow is the equivalent of the main branch we just discussed and github flow and the master branch is where all your actual deployments come from your actual you're releasing to your customers you're releasing to the public that's where all your releases come from for the actual release product years version 1.0 2.0 3.0 you can also obviously do incremental releases beta releases off of other branches but the main pushing of application code comes off that master branch so as a result of that we will see within this picture is that a lot more commits in the develop branch as opposed to the master branch because that the final merge into the master branch is a one-time operation once you only merge the master branch once you're actually ready to deploy actually mention as well the pictures from the github flow they all come from the github flow tutorial on the github website so they link to on the bottom to take out to there and all these pictures came from the very very detailed successful branching strategy model blog posts encourage you all to read if you haven't had a chance to look at that so then get up flow or within gift alright again it's the same premises github flow if you're working on a feature you take a branch of the develop branch you do your work in that feature branch and then you merge it into develop so again four or five developers all working on the same a different set of features have those active feature badges going and then merge back in where where it comes to be different within git flow is that you also have this concept of a hotfix so you're in a situation where you deployed what you think is the perfect one point or release on to the production servers and you've already started working on the next release so in your develop branch of all that you've got a bunch of code checked in and merge into the develop branch and your customer forms up and says something's not working this is where get flow kind of steps in get full allows you can see take a take a branch off of your master branch to do an emergency bug fix release so you can do a small subset of a fix do the work in that hop expansion and immediately merge into the master branch but it also allows you to merge that work back into the develop branch so in your next major release you've already accumulated that bug fix and you haven't had to duplicate the code or do the work in two places so that's the fun one of the fundamental differences between git flow and github flow and this is this for me with some of the open source projects that I work on this is really why we start to use git flow is because we can push out those convicts patches and those public releases website pushing out features that aren't quite ready for for prime time and only so this is why it's perceived is more complicated because those three little segments that I showed you it's ballooned up into this and this is the first picture that you'll see on that blog post and it's actually quite quite quite it's quite scary because it's like it's a mash of branches and commits and version numbers and you just think oh my god what's going on right but it's not once you start breaking it down into its constituent parts it is really just the github flow portion and two miners individual sections of this overall picture so I highly like to think about that as opposed to the more complicated overview diagram so the takeaway from that is it's not as scary as it looks okay it is complicated and it can depending on the implementation of it cause problems but I encourage you all to look at that and just take a step back and understand the principles of it green the green line there is so the green line that's right so the green line is not similar parking watch that's not Eminem's the green line urgent request like that release branch so in the same way that you have a hotfix branch that comes off of master and then when you do the work you margin may develop and master finishes the green one is actually when you're ready to do a deployment order ready to do a release you create a really sponge because as we all know you don't always work in the develop branch and you've got ready and then you're ready to ship it and you find the bugs take away so the idea is there again you committed this is everything that's going out the door and that release so at that point you find the bug once you put into your QA vitamin or whatever you would fix the bug in that release branch and then when not release by its finishes you again merging into develop I'm in the master so that that work isn't washed again it's questions or minuses so the question was whether get flow is more applicable to deployments to NuGet or whether it's for war but internal I personally don't see any I using both I use it for both internal application down for ultimately deployment you get the principles are the same ultimately you have committed to a fair feature of a set of functionality that's going out in that release whether it's being deployed to Newgate or whether to deploy in tournaments and microservice for me is the same thing yes internally so the question there is the true spiders are for your to internal the internal testing servers that's exactly it once you go to a point where you are half baked and all the all the sprint backlog games within that release are are finished you create that release branch and that's what goes on to your internal QA servers that's potentially what you find some issues you fix those issues but it's important thing at this point is that once that will be sponge is committed you're not then adding new features into it because you should have already finalized those pictures before that release branch but compared the release branch is committing to and deploying the Steyr features that's in there and so the bug fixes you might fix are only related to a situation ok so again this is a whistle-stop tour of branching strategies but lots more to this and we can talk lots lots about it but this is intended to just be a very very top overview of what that is so with all things in mind so we've talked about semantic versioning and we talked about branching strategies then we come to this thing called git version and we will need have a chat with what that is so what is get version so get version is a tool to help you achieve semantic versioning of your project so that is directly from the github again give version website and it really tells you nothing about what the conversion actually is so what is that what is what is it really so get version is an exe or depending how you run it it can be named as build tasks as well get version is a tool that will run against your cool commit ready repository history so it will actually look at your commit history in your repository and it will assert a version number so what I mean by that is it will look at the entire industry and say what branch are you want how many commits have you made what what's the shy of the commit and it will generate a version number for you so an example of that just to scale just to put it in context so what we've got here is this is my github release demos github project what you're seeing today if I run git version on there this is what you get so get version is outputting a lots of different conspicuous parts of a verb a version number so it will it will find things like what is the major minor patch it will find out what pre-release tag raw and how many commits we've made into the repository what branch Ron what the shiz all of that information and it will format into these variables that you can ultimately then use and put somewhere okay so what I mean by that is for instance if I show you if you see there the informational version one in the middle of the screen there as I said that's likely every one because it contains all the information it's got the branch name the version number the char every piece of information that I want for full traceability of my application so fundamentally that's what get version does is a utility a tool that will assert that version number good we'll the question was Clarissa major/minor Patrick will come onto that okay I'll hold that for the devil but yes ultimately go to answer that question okay so get versions there's a few other things but it's sort of changing and get version will also help you with updating your assembly info dot SES and your assembly info TB files it will also attempt to do things like updating port date JSON files as well but I like to think of git version fundamentally as a tool for asserting the current version number of my repository that's what I use it for I then use other tools and other orchestration pieces to use that where's number to do stuff with but keep in mind that get version does do some things for you with regard to updating version numbers for you quiz needs to happen okay so as a so I'm going to stop there because that's that's what conversion is that's what conversion does and we'll come on in the demos as to I will press all this thing together the one thing I would say about git version is that although it's our utility tool for asserting the version number it's not a tool that will help you decide when that semantic version number needs to change so what I mean by that is how do you decide whether it's a bumping the patch version number whether it's pumping the minor but that's not in the major there are other tools from the guys in particular that you can speak to Adam about there that will help you make those informed decisions the dual carry decisions come from actually looking at the codebase and saying well this method has added a parameter so that's fundamentally breaking the API of that method signature so that's that would be a major version bump so there are utility tools again you can use that will help you establish when those things occur get version is making an informed decision about the semantics version based on the branches and commits you have a new repository but just to keep those two things separate separate pieces of separate but related pieces of functionality uniquely application so the questions comes and what I'm hoping to address is why do we need kit version so you need get version or you need to assert version numbers because historically what we've done is we put a version of txt file and our repository and we manually update that when we think the version number needs to change and process what happens is that that gets forgotten about and that just gets less as 1.0 from zero and it's never looked at again and so if you're in that situation or if you're in the situation of manually bumping version numbers in your assembly info dot CS or VB or vs files you're in this situation where you've got what people refer to as the human factor you have that human involved who have to remember to do that if you use something like version that always knows what the version number is because it's serving it based on the history of your repository then that's one less thing to go wrong okay the other thing you could do is you could have a CI system so this is a screenshot of team say we're team say it can be used to actually provide at least one piece of information for a version number which is the amount of times it's been built so it's a build number that can be used to automatically pump a version number of your application because that build characters when they increment every time the build lines and that can form your version number or leave part of it the problem that I have with this as much as I love team say and I like to use it this for me is coupling yourself to one vendor our CI system so again with something like git version which is reading the contents of your repository and the history of your repository then that version number follows your application around you don't need to worry that it's running on a build and team CA or running on a build and a player or running on a build on and insert your favorite CI system here or you need get version because you actually don't know what the hell you're version number of your application is at all and you just push it on to production server and you don't worry about it or you do whatever I did but you don't care so that's why I think we need something like get version because there's plenty of these out there and I've known projects that just are built on an individual's machine and the result of that builds are straight lines productionserver we've all been there but this is what I'm suggesting it's not the best way of doing things and we need to do things and a more managed way so the next question that I'm hoping answer today is what release manager first of all is the longest name for a utility tool that is probably but it's not my fault it's a guy that particular fault and get release manager actually started to the tools to get release manager is a tool that will help create asset release notes for your application or product so again release manager or as it was called then the github release manager started as an application within particular the decision was then made I have to speak in the simon crop to pull that into what's referred to as a get tools organization and github so rather than particular owning it and we brought it into a standalone organization and we changed it to get release manager the intention was that that would then become a utility tool would work on all the major sort of control systems out there the bit buckets they get labs all the things that hasn't happened it still only works against github and but it's been called lease manager but one day hopefully it will get to be a product that targets all all those things so what is it really github release manager or get release manager is a again a utility tool that will attempt to create a set release notes for you so one of the fundamental tenants of this traceability that I'm aiming for is a concrete set of the lease notes that correctly and actually describes all of the bugs the features the improvements that went into a release that's something that you give use you can do that manually you can fill those release notate manually again but that subject to a human error and things getting missed so I like to install or I like to use a small amount of process and we'll get to that a second to control through github issues or through whatever tools you have me to be using a small amount of process that controls what issues are going into release or or the terminology of get up into a milestone and by doing that small amount of process the end result has already been established for you all you're doing with get really giveaways manager is creating that several these notes based on again the history of the project and that issue of the project has been in your source control repository so it's a tool just like get version that you run got a bunch of parameters that you send them to it and magic happens so what we're going to hopefully see if I putting all that together then demo that we can from end to end create or assert a version number take that version number and help us describe the cell release notes that ultimately go into our finished product so before I jump to a demo are there any questions on what has been spoken about so far while I grab a quick print no okay so I'm going to sit on chair and we're gonna start doing demo so what it showed before was that is the certain version number from me running on my develop branch so as I said get flow is my preferred branching strategy and the get full demonstration for get version shows most of its functionality and get version as a product works with pretty much all the major branding strategies that are right there this demo specifically shows how to work it with skip flow but it will work on other brand new strategies as well yep when you want to push into prod a little more cautiously about the battery sinker to build and this video I'll cook there's a real problem with that it's not same so so the question is if on a release branch that you push that to QA and ultimately you've tested it you're ready to push it out to the to production when you merge into master it's not the same one yes that's a different topic entirely and not really being covered with the minister I see what you're saying though but ultimately and a get full scenario that what it specifies is that releases come from your master branch so on that release branch it should have everything up to and including what's been cut into that release branch so although it's not the same binary the output of that binding what is built off of the master branch should be exactly the same thing but there are other strategies you could use in terms of taking the artifacts that were created on that release branch and have that as part of your build pipeline so that when you actually merge into master you're not actually building again you're just taking the artifacts from your release built so there's techniques that you can do to do that but it's a much bigger question Adam is going to say something and concerns we have a new package chain with the same code and boundaries so when we do it when you version master Jesus factory where yeah what if you are following dip flow and everything's gone correctly then what gets built in your master bag should be the same as what's in that release punch because again you you're following that flow and you've cut from develops you create your release you've done some bug fixes and ultimately what wasn't the master branch is what was in that release package but yes you're right it's not the exact same Bailey and it breaks the principles of all the building once and only deploy once and all those sort of things from a pragmatic point of view I would argue that it's the exact same thing and at that point at least you've got a fully stamped traceable version number that you can go back through your history with but again that's a much bigger topic that I'm not going to cover today so we can talk about later if you have one okay so we're on our develop branch we'll start with this version number the important things to look at here is that for example if you look at the full cember there then we've got a zero point one point zero unstable point three nine so the three nine there is telling me there have been 39 commits in this repository since it started the unstable economy is coming from the develop branch I'm using us I'm using the non beta version of get version here in the new version of get version is a we come out that will revert to saying alpha there rather than unstable that a long history of violence table was chosen as a default branch name for get version on the develop won't go into it but going forward that's going to say alpha the question that you had earlier is where is that zero one zero version number coming from and how how is that controlled so the other said the first version number four from a semantic version point of view the first version number is always zero one zero so if you haven't tagged your posit or a get version also works in the concept of tagging if you haven't tagged your repository as being a different version number then the base version number that all with a zero one zero you can control that through commit message so specific commit messages into the positives using get version will actually bump specific version numbers or specific portions of the version number the box default you're going to get zero one zero always until you release zero one zero or there's a get version also has a configuration Yama file that allows you to control the start in version number so let's say you want to add option on to the existing product and you're already in version 2.1 point seven then you can specify that if your base version number four dip version to start a start in front but out the box you're going to get zero one zero okay so what I'm going to do is I'm going to check out I'm going to do some work I'm going to I'm going to create a feature branch and I'm going to do some work on that branch and see what gate version does so let's just go ahead and create a feature branch called DDD twelve and we're going to take that we're going to take that from the develop branch I can't type it out okay so we're now on a different feature branch we haven't actually change any code at this point I haven't changed any of the source code or but odds on a switch a branch but if I run git version again then straight away you'll see that things have changed so rather than being on my unstable branch I'm now getting a version that's coming from the branch I've just created again the thirty-nine hasn't changed because I haven't made any commits but it it's telling me that it's coming from a different branch so if things are different between branches that shouldn't be again you've got a full traceability back through to where that building in from if I actually go ahead and do some work here I'm not going to do some work I'm not going to force you watching try and test and do some work I'm just going to create an empty commit and I've run git version again then what you'll see is we've now we may bump the version number we've now got an additional piece of work went into that repository and we've jumped up to number 40 so it knows through the commit message here through the commit number of commits since the the branch has started or since the development started that we're for Cle along that that process so that's really the like we thought over the equivalent of like your build kinder in team say so wet every time you are running a building team say or Jenkins or wherever your CI system is that's the number that's going to fall with it but that's based on commit now not wanna build that seems a volcano question yes so the question is if an get you squash out a bunch of commits or you rebase a branch and you squirt clear opportunities quarterlies commits then at that point your version number your certain version number would reduce at that point because the commits that are on that branch have squashed in so you may have made three commits and you go to 43 and you come back down again because you only use squash floors and use them more in them but ultimately the important thing here is this is telling me this is a feature branch there's a feature branches you'd never make it onto any sort of production server so the actual asserted version number at this point is not that important but from a traceability point of view is but from an actual viewing area to the customer they would probably never see this one anyway because on a feature branch but the mergers in to develop because master and develop are your primary branches rebasing or squatting commits one to those that's just platform just just don't do it because then other people have to then reset their own as clones of that repository because those are the two main branches so just don't do it but squashing in a feature branch fair play it is corporate okay but the version number you're right the version number may be slightly different but the shy the shy of the commit would be different so again from a traceability point of view the because a char has changed you would still know where they came from okay I saw I'm going up but ultimately this what you're saying was so the glitch was and the commit member would still be the same actually wouldn't because if you did commit commit commit and then you squashed it into a single commit then because can get version is accounting from the start it gets to that point there's no longer the 42 and 43 that you could've had yeah exactly so the good okay yeah so ultimately we can do the same thing again so I do another commit in here this is kind of laboring the point a little bit but if I do another commit and then look at the output then what we see there would want that commit number again so we're now at 41 so again from a traceability point of view we're nowhere yet so if I go ahead and do a check out or yeah check out develop again and then merge that we've finished with that release or that feature rather I'm going to merge that into develop and run git version again then nothing much has changed here but we've seen that progression we're back on the unstable we're at 42 now because we had that merge commit so in addition to the two commits that we made on the feature branch we've got the final merge commit into develop sub network fortitude okay so we've now got this amazing features and we fix all the bugs and we want to create a release so again what we do is video clip check out and we're going to do a release plan sustain and because of this circuit version number we know that we are working towards that zero one zero release so from a convention point of view get version doesn't care but from a conversion convention point of view I always name my trollese branches and then ultimately the number is going to great because at this point you're pushing out code to your coins to your customers you should know what the version number is marketing's decided that this is the version number and you google it okay again that's an interesting topic that won't get into that square that's where that's what we are so I'm on this release bench just clear the tape again and we'll run git version so at this point not having made any code changes but again I'm now on my own now an updated release and a release branch so get version has asserted that I'm on the zero one your beta beta one and then again the commits along line 42 so at this point to tagging you can actually have multiple betas so you could actually tag this as 0 1 0 - beta dot 1 and then get version would create a second beta 3 beta 4 there so if you've got this release pipeline Pro you actually rolling out release candidates again get flow and get version accounted for that and you can see how that can flow through so we're in this situation where we have found a bug so we do a commit so I'm going to do a lie empty again this again is labeling the point I just want to make sure that everyone's on the same page we make a commit so again we're so on beta that we bug net 43 nothing else to change but the actual meta data that's being added into the version number has bumped along the Shires bump so again that full traceability comes through so the final thing that we then do in agate floor scenario is we check out the master branch and then we would merge the release branch into master and at this point if we want it version at this point we have a semantic version that's doesn't have any additional permission doesn't have the branch number branch name it doesn't have some other other metadata it's literally I'm at this version this is the release version so at this point this is when you tag your repository at 0 1 0 the we're at position now where we have done all of our development work we have committed into a source control repository and what we want to do now is we want to create a set of release notes that correctly conveyed from a traceability point of view everything that went into this release so this is where the small amount of process that I mentioned earlier comes into play so if you're slightly obsessive like I am then what you actually have is on your github repository or on Europe whatever was in your issue tracker you have a set of issues that are the things that you want to achieve with a nice what I do is I tag or I assign each of those issues to a milestone on github so everything is going into this release this milestone has an issue associated with it and each of those issues is labeled with a piece of information to indicate what that is a functionality is that documentation is an improvement as a change in the build system is a bug that features a breaking change or whatever so this is where the process comes in and this is where the manual effort does command but bottom line is you're not going to get away from all that work things have to be done and there has to be some sort of due diligence but where I go a step further is that when I make a commit into my repository I always use this tagging feature that github and other source controller systems have where you can link a commit back to an issue I like that from a traceability point of view because I can then look at my commit history and I can click on g8 7 which was my create slide deck for this presentation and from a history point of view I can see all the commits that went into making that issue okay that is not a requirement for everything I've discussed but that's just what I do again this traceability thing that I'm talking about here so what I want to do is I want to run git release manager now that I've got get working correctly asserting that I'm doing my 0 1 0 release and I've got a zero 1 zero milestone and github I can use get release manager to create a set release notes that includes all of that information so the first thing I would do here I would have normally done this already I would close these issues as I actually commit them into my develop branch but just for the sake of argument I'm going to mark all of these are closed so assuming that my internet connection works I go so at this point all those issues on that milestone have been closed and if I go to the releases section and gap for those of you unfamiliar github has a section that will list out all the leases of your project and give you a space to add release notes into that some people choose to have archived release notes or MD or I change logs or MD in the root of the repository I like I prefer source of truth my source of truth is the releases in github again that's a personal preference so at the minute I don't have any releases so what I'm going to do with the command-line because I am going to now run get release manager in order to create that set release note however get release manager needs as an input the version number because it needs it doesn't assert the version number get release manager is solely focusing on controlling the release within github so git release manager actually has a dependency on git version so what we're then talking about is essentially build orchestration we need something to build out get version and get release manager and any other pieces of functionality we need ultimately whereas if your build and all the other stuff but this is focusing on the deployment side of things so for those of you that know me I use cake for pretty much everything and there are other build orchestration tools out there but cake is the one I choose to work one it's got nothing to do with the fact that I'm a contributor to the project I just think it's good and so what I'm doing here is I'm using a cake script to start that build orchestration node so what i'm doing here is get release manager requires that we have a username and password for starting we don't want anybody and everybody adding releases onto our github repository so has a requirement for username and password so what we're doing here would get in credentials i couldn't store it as a vitamin variables then i'm going to one get version which is exactly the same things we were doing on the command line I'm just using cakes functionality to do that and what I'm doing here is I'm just I'm just writing out those version numbers all right to them on the command line and then what I'm doing is I'm using a task which is to create that set release notes on our actual github repository so if I jump back here I'm just going to build not build this running cake so all this part all this is going to do is do the exact same thing we're doing at the command line which was to assert the version number so you'll see here all we're doing there is I'm inserting that nice big long version number that I like and also the semantics version number so that's all that's happened there we haven't actually done anything to get hub at this point so if I go back to get up and refresh the screen there's nothing there all I'm doing is women get version but if I go to the next step in the build orchestration and a value on the target let's called create release notes and what's gonna happen it's still going to run get version because again get release manager needs that input version member and then it's going to go and create set release notes for us so it's finished so if I go back here now what it's done it's looked at the content of my repository and all the issues that are saying to that milestone that is zero one zero and it's created a set release notes that includes information that ie the the title of that issue so that again there's a little bit of due diligence and that respect to make sure that the issues that you're creating are reflective of the actual thing that's being fixed it's not it doesn't know what you did in that issue but it creates a set release notes that includes in a in sections all of the issues away into that so again from a traceability point of view from this set of release notes I can then go to issue number seven which was the creation of the slide deck I can see all the commits that went into that I can see who was working on it and where I can see where it was linked to the milestone and all I saw is that so that's there where it's quite is coming from okay and the at this point what it's done is its created a draft release so this has actually gone out to the public no one else can see that apart from people that have access to the repository it's it's a draft release you actually have to come in here and say publish the release before to actually goes out the door okay but that's not all so the other things that you might want to do is that as part of the release on github you might want to actually take the artifacts of that build you might want to take the new get package or the software package or the MSI of the exe and add that as an artifact of the release because that made before you want people to actually download your application from so the other thing that release manager does is just that so what this is going to do now I scroll down here attach artifact and then all this is doing is running to get release manager add assets function and it's going to take a list of files that what you want the ones you want to attach to that release so for this example all I'm doing is taking out license file that you see there on the left I'm going to add that as an artifact of the release on github so again if I jump back to here and I run this time not that and I do attach artifact then what we'll see again I'll run git version start the version number assert the version number and then run that attach artifact and if we go back to here now when our github release and do a refresh then in this downloads section we've now got a leak or a license txt file or an empty file but imagine that could be your new get package or your MSI or your Exe or your zip file whatever your artifact is it's now on github and the final thing to show from that point of view is that from again slightly over compulsive side of me we've now got a milestone that's currently open so we now know that this release is finished because we've created outside release notes the types of artifacts we should really go ahead and close that milestone to give an indication things that finished off so you could come in here and just click close but we can alternate that as part of our release process so if we come in here and say close milestone and let that run so again I'll start the version number they'll close the milestone if we go back to here now I hit refresh now it's now closed and it's in Gibbs history as this was a milestone that was completed here are all the issues from a traceability point of view I can see all the commits and editing went into that so those three things I showed as being actual separate things as a full build orchestration you probably do them as one one task or one set of tasks that was the actual pushing out of the final application that you're that you're making okay what I tend to do in this kind of speaks to the point of your meeting or I make it and when I do a commit why do my final commit on to the master branch typically what I do is I have my build orchestration run the creation of the get release notes so the find out that the first margin to master creates the release notes and then I'm left in a situation where I have a draft release and then what I do is I will trigger another build based on me publishing the release because what github actually does is when you hit publish release it'll actually tag the repository for you as well so I'll actually trigger another build that will take the artifacts from the last build and actually push them out onto new gay Chalkley whatever that word artifacts cool I've done my build once and then the second bill which is actually I'm happy will take all the artifacts can push them out to where they need to go so there's again a two-stage process there one is the merge in the master spinal sanity check that you're happy with all the release notes publish the release actually get another build that just does an actual deployment of the artifacts on that release that's another again the build happens once but that another portion to go over to the deployment tab okay and that was the demo that I had or get a version and get release manager now I go back to here my question is now are there any questions about any of that because I don't have anything else to show you so any questions a bunch of resources here for additional information about git version branch and strategies in general Jake in 'van one of the main contributors to the get Barton product did a lot net rocks episode so there's more information on there these slides all these slides are all available on my github account which is just G EP 13 so feel free grab to grab them so yeah any questions you

Channel: Gary Ewan Park

Views: 8,162

Rating: 4.9183674 out of 5

Keywords: GitVersion, GitReleaseManager, Git, Semantic Versioning, GitHub, Branching Strategies, DDD12, Reading

Id: SlM02V1tkSc

Length: 49min 20sec (2960 seconds)

Published: Sun Jun 11 2017