Semantic release tech talk

Apiary internal tech talk about Semantic release

Transcript

1. Semantic-release
2. The problems
7. There is a better way
8. SemVer recap: major.minor.patch
9. Semantic-release Automated package publishing Takes care of publishing and versioning. Helps with keeping changes trackable. Scary docs https://github.com/semantic-release/semantic-release But in reality, it's pretty simple
10. It's all about a commit message <type>(<scope>): <subject> feat(scopes): Added user:settings:integrations scope
11. ☞ feat: A new feature ☞ fix: A bug fix ☞ docs: Documentation only changes ☞ style: Changes that do not affect the meaning of the code ☞ refactor: A code change that neither fixes a bug nor adds a feature ☞ perf: A code change that improves performance ☞ test: Adding missing tests ☞ chore: Changes to the build process or tools
12. Yes, you can also define own types
13. How do they know? Semantic-release will decide on next version number according to type of commits you are merging. For example - docs won't even release - bug will do a patch You can note a breaking change (thus forcing major) by adding text BREAKING CHANGE in your commit message You can also do dry-run before pushing.
14. npm run commit
15. Getting it to the repo See this PR as a reference github.com/apiaryio/bob/pull/8 ➀ Install deps (semantic-release, commitizen, cz- conventional-changelog, condition-circle) ➁ Setup GH_TOKEN and NPM_TOKEN (with CLI tool) ➂ Update package.json (crazy, raqe-inducing part) ➃ Add npm run semantic-release || true to CI deploy step
16. End notes ☞ Video tutorial on setup: https://egghead.io/lessons/javascript- how-to-write-a-javascript-library-automating-releases-with- semantic-release ☞ Semantic-release is also fully pluggable ☞ Your versioning should start at 1.0.0 (per npm recommendation)