Exercise: Automating Releases Part 2

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Speaker 1: I'm going to just get checkout. This is gonna basically take the files that I give it and revert them back to what I had before. The package Json and the .travis.yml. And so now if I look at my status, like nothing actually has changed. Then I'm gonna manually go make some of those updates myself.

[00:00:27]
And actually you can look at the changes in the git-diff to see what we need to do. So one thing that I'm gonna do is I like to, get rid of that I do like to have a version in my package.json. This is actually following semver's specification, so you can have the three numbers, and then a dash, and then any arbitrary string.

[00:00:54]
And so that just basically indicates just the reason that I don't like totally removing the version is because when somebody comes to the project and looks at the source code they're like what on earth? Why don't you have a version they're wondering? And so if they see 0.0.0 and semantically released, they're gonna scratch their heads a little bit, but at least they know okay there's something kind of special about this.

[00:01:17]
>> Speaker 1: And then maybe they'll look that up and find it. And if they see it enough, then maybe it'll, they'll know exactly what's going on here. So that's what I'm, these are the couple things that I'm gonna do. I'm gonna add that release script back in, because that is important to have.

[00:01:36]
And I'm gonna add semantic release in here.
>> Speaker 1: And that was 4.3.5, I think, something like that. And add that version back in.
>> Speaker 1: Or just replace the version with 0.0.0-semantically-released and then finally in the .travis.yaml, after_success, after we report the coverage we're gonna npm run the release script.

[00:02:16]
>> Speaker 1: So that is that.
>> Speaker 1: So the changes, just again, update the version, add a release script and add semantic release to your package.json. And then add in the after_success, npm run release.
>> Speaker 1: I'm gonna be really excited if at least a couple of you get this working.

[00:02:42]
That will be awesome. There's always, when you're doing it for the first time, it's hard to kinda set up, but after a while, it becomes pretty simple to do. And I haven't even gotten to some of the even finer points of benefits of automating those releases. I'll get into that in a little bit.

[00:03:03]
So I'm gonna go head and commit this. Actually hold on a second. Before we commit,
>> Speaker 1: My slides, I'm kinda diverting a little bit from the slides
>> Speaker 1: So yeah, I think before we commit this, we're gonna set up the next little thing, and then we'll commit it all, and hopefully, it'll all just work.

[00:03:30]
When we push it up. So let me show you the commit message conventions. Let's see, commit message convention, or actually, validate.
>> Speaker 1: I'm pretty sure I've got a link in here somewhere.
>> Speaker 1: Yeah, here we go. Okay, so these commit message conventions originated from the Angular team. So they're the ones who created it so they could automate creating their change log.

[00:04:05]
And this is the basic example of the idea, this is one that is closing something. This is one that is closing an issue, an existing issue. Or a pull request or something. This is one that has a breaking change in it, so this would result in a boost of the major version.

[00:04:29]
And then there's even room for reverting and stuff. But the basic format flow is something like this. So you start out with a type, and the type can be feat, fix, perf, docs, chore, style, refactor, and test. So those are the default types. Then you also have a scope.

[00:04:53]
So within the context of Angular, if you're familiar with Angular, $location, $browser. This is maybe features, or if your library has a command line interface you could say the CLI. Or you could say for us that would be random, or it could be all, or you could also do names.

[00:05:14]
So it's whatever, the thing that is being changed, and then the subject. And the subject is an imperative voice, so it doesn't say, it changed, or changes, it says change. So you should think of it like this, complete the sentence, if this commit is applied then that will change this or update whatever, or document this new feature.

[00:05:49]
Something like that. So the reason that you want to use that kind of voice is because when it's generated as the change log it kind of reads a little bit like it makes a little bit more sense. Then you don't want to capitalize the first number, and no dot at the end.

[00:06:06]
That's just kind of the convention. Pretty much all through these points aren't required to make all the stuff work, these just kind of nice things. Then you also have the body, so you have a blank line and then the body. That's where you describe a little bit more stuff.

[00:06:21]
You want to use the same type of voice that you do in the subject, but you would have a little bit more specifics of like why is this happening? Why are we doing this? What do you need to change about your code if it's a breaking change. And then you have another blank line, and then the footer.

[00:06:40]
And the footer is the place where you can put any breaking changes. Or if this commit closes, any GitHub issues, it says closes number whatever that GitHub issue is. And then based off of all this information semantic release can generate some really solid change log.
>> Speaker 1: So that is that.

[00:07:01]
It seems like it's pretty strict and it might be hard to think, could I really get this right? And so if you're a little bit worried about that, never fear. There is a tool to generate that. And there's another tool to validate that it follows the convention. Which we're gonna look at next.

[00:07:17]
Any questions before we look at that?
>> Speaker 1: Anybody kind of wondering is it really all that worth it? Is this worth the effort? It is. I'll just say it. Okay, so, as somebody who spent hours updating in change log and all that pain, it is totally worth the effort.