Это видео недоступно.
Сожалеем об этом.
Version and Automate ⚡️ Releases like a Pro - Walkthrough and Demo
HTML-код
- Опубликовано: 15 авг 2024
- Experienced #DevOps engineers know when to deviate from a standard. We know how to think for ourselves. Watch me automate a release changelog and explain why this breaking change is NOT a new major version and look at HashiCorp's Terraform example.
00:00 Intro
00:40 Choosing a SemVer number
02:28 Why not 1.0?
03:45 Automated Changelog Demo
09:40 Conventional Commits and Discipline
14:12 Closing
===== Links from Video ======
Semantic Versioning Specification (SemVer)
semver.org/
Conventional Commits specification
www.convention...
Standard Version Utility - what I used to automate my changelog
github.com/con...
Resulting Changelog
github.com/Azu...
Article - Announcing HashiCorp Terraform 1.0 General Availability
www.hashicorp....
When I saw u r Devops videos I am very happy coz learning new things in Devops technology..Thank you
You're welcome! Happy the videos are helping you learn - that's why I put them out there :)
Power packed 14 minutes video, Thanks for that!
Glad you liked it, thank you!
You deliver great content in your channel! Thank you!
Thanks foerfinad! It's a reminder to make more videos :)
Thanks. Good to see you back 👍🏿
Thank you Ikechi. It means a lot to me that you noticed and care 🤗 motivation to carve more time out at work to do this for you and others like you :)
I wasn't able to watch the entire video yet, so I'm not sure if this is answered: What about really trivial non-breaking changes - say, for example, a text change - would that bump the MINOR number or the PATCH number? This has always stumped me because It's not really a new feature, nor is it a bugfix...
Uptalk, vocal fry and strange back-of-throat inflection - strangle mode. LOL.
stinky feet :) thanks Julie. I stumbled across this by accident. I love your candid and unscripted style! Keep going! thanks. Subscribed.
Thank you Felipe ♥️ reading your comment confused me for a second... but then I re-watched and laughed myself. Thank you for the reminder my fast brain is snarky 😅 and that I can be myself 😅
3:19 you're actually following semver by choosing 0.4.0, since semver allows breaking changes between minor versions if the major version is 0
Indeed. I meant that even though it's a breaking change, I am incrementing 3 to 4, although strictly speaking, it should be major version, so a 1
@@JulieNgTech what I mean is that semver agrees with the principle that before 1.0.0 "all bets are off", there's even rules specifically meant to allow that.
BTW, do you really find it productive to use git on the command line, or are you restricted from showing a specific GUI client on your videos? I don't normally shy away from the command line, but when it comes to git I find it terrible to get a good grip on the graph without a GUI
@@leopignataro using the cli is faster in the most cases, also if you are using custom aliases for some use cases that appear often in your workflow it gets even faster and for the other cases, you could use a TUI like lazygit. Not having to jump between the coding environment and the browser to manage git is much faster than going back and forth the whole time.
Terrible idea if you plan to do this while in production!
To be fair to Hashicorp, semver makes special allowances that the major version doesn't have to change on breaking API changes when at 0 [see #spec-item-4]
1. how can developer determine the changes will break things or not?
2. How to force users to follow the commit standards, one thing that makes me confusing is where the commit fits in , its either chores or fix or bla bla, kind of a long list .
How do you do this?
I always prefer that kind english, great video
Thank you Josh!
So which branch would I run standard-version on to up the version? If its feature-branch > dev > staging > main. Wouldn't I have to run this on a feature branch, and then merge through to main? Dev, staging and main are protected, so I can't commit the new version/change log straight to them? Then it seems like a lot of work to go through all those CI pipelines on my dev and staging branches to change the version. Would I have a new feature-branch like 'increase version' before a release? If I did it straight to main on a merge, then my other branches are behind because of the updated change log, which seems weird? I'm not sure if that makes sense but yeah, just which branch am I running this on, and what's the ideal workflow?
Great questions Isaac :) You're right, that is too much work for a change log, which is why I don't strictly use the PR workflow. I generally enable branch protection, but I give myself as admin possibility to bypass it. Generating a changelog is one reason why.
I think PRs are good, but don't need to be used 100% of the time. There's a great analogy that forcing your team to always use PRs is like forcing your family through airport security multiple times a day.
When you say the other branches are behind, which ones? If it's the feature branches, as part of best practice, you should always grab the latest changes from the primary branch before merging. So for example, if you primary is dev, I would always do `git pull origin && git rebase origin/dev` to grab those changes before merging my feature branch. Does that make sense?
@@JulieNgTech Yes, thanks very much for replying, that makes a lot of sense. Appreciate it!
this is extremely useful. Thanks a heap
Glad it was helpful!
Great solution thank you for sharing this video
You're welcome!
what a great way to start a video "0:07" knowing that you have more important stuff to do and this one is going to be a quickie. Ok, important woman, keep going...
Do you have an actual comment on the information shared in this right to the point video?
It wasn't intentional 😬 I'm actually a lowly individual contributor in a giant corporation just trying to squeeze in some content for the wider world 🤗 - not just the Azure customers who can afford the program I work for.
@@JulieNgTech and you did it again "...customers who can afford the program I work for" reinforcing your self worth. You feel the need to reassure your professionalism and express how proud you are of yourself to be a cog on a giant machine. You did it, you are hooked into the big corporate machine. Slow clap. You have that pro look/vibe so don't worry about people not getting from you anything other than the feel they are talking to a successful profesisonal. But don't be pedantic, no need to point out or make reference to what you already emanate. Your mom and dad must be proud of you, you did it... now let us, humans, listen to you without looking at the Dorian gray painting showing us how little we have accomplished in life.
@bandinopla dude you have some serious issues.
I really miss your videos !
Me too! But good news, more videos coming soon :) Only a few weeks ago I semi-formalized an agreement with work to spend workweek hours on RUclips.
In the coming months, you'll see a Cloud Design Series that will teach folks how to think like an architect. Stay tuned!
What if I not using node? Does npm is still required?
Great video! This package is now deprecated what are you using now?
Thank you
You're welcome
really great stuff! I was looking for insights with semver and pipelines for a while... Althought it clarified some stuff, I'm still thinking what the best strategies for branching and semver would be... maybe a main, with the stable tags and a beta or rc branch with pre-stable tags and an unstable branch. This way I would do PRs from Unstable to Beta and from Beta to main, running testing and tagging on all 3 of them on a CI pipeline and running changelog only on main pipeline... does that make sense?
If it makes sense for you, give it a try. That's the only way you will know if it works - and if it works over time is to build it and use it. Just be aware that the promotion concept you described is straightforward… it's the git branching workflow that we all usu. trip over. The fewest people are that disciplined to be able to manage that many "active" branches - myself included.
Anyway, sorry for long delayed response. Did you end up trying it on your own?
Great stuff, thanks!
Thanks Wazz! If you find this useful, please share with your friends and colleagues :)
@@JulieNgTech Will do - keep it up 💪
Hi thanks for the video.. i have one problm like when i am running on my feature branch the Tag version is 1.0.1, whn merging with the Develop Branch its getting changed to 271.1.0,but i want to be with 1.0.1 version for the Client SDK and the Data N Service Dll... but why its getting changed? any idea
Those types of questions are very hard to answer based on a few sentences. But based on fact that `1.0.1` is very different form `271.1.0` there's a workflow issue here where stuff is happening in parallel and not aligning well. You should be able to see from `git blame` who made what change. Go talk to them and figure out how both your actions and workflows work together. That's just a guess, but talking to people is generally a good first step.
@@JulieNgTech thankyou for you reply. will do the same.
@Julie Ng, Thanks for the video, great content. Is there a way you can share your gitconfig aliases 🙈 ?
Yes, of course! They are open source at github.com/julie-ng/dotfiles/blob/main/.gitconfig
and if you want you can view all the other dotfiles in the repo :) Enjoy!
@Julie Ng Thank for the video. Could you do a video/walkthrough of pre-release management, releasing a pre-release and then syncing the released code with dev branch that might have progressed further since the pre-release was cut please? I am not sure if I could articulate the ask well, hope it was clear enough
Hi Chandra, sorry for late response. When you say "might have progressed further since the pre-release was cut"… if that was also cut from the dev branch, there shouldn't be any additional changes that need to go back, no?
Or are you talking about bug fixes?
@@JulieNgTech Sorry for the delayed response, yes I am talking about big fixes. Another scenario is, you cut a release branch that goes through some verification/testing/sign-off which could be few days and the eventually gets merged to main branch, changelog gets generated, a new commit is made with changelog/release notes etc. and realeased to public. While this is happening Developers might start working for next release and might have pushed some commits to dev branch. Now when it's time to merge master back to develop, bothe the branches are diverged. I wanted to understand how to handle conflicts specially around change log, package.json etc.
HELP
🛟
not for noobs like me. unable to understand well.
Hi Hitesh, yes, this video is not for beginners. There are other videos on RUclips that probably will work better for you.
Please use dark theme. White backgrounds make videos unwatchable
Is there a more amateur video..