Choose Your Own Tutorial
Writing your own Dist::Zilla VCS Integration
Dist::Zilla does not use any kind of VCS middleware like VCI. Each plugin for VCS integration is on its own. The framework that is available is the standard set of Dist::Zilla roles for plugins. Before you can write your own VCS integration plugins, you'll need to understand how the build process works so that you know what roles to use to get the behavior you want.
Here are a few tips on what you're likely to want.
If you want to make sure that everything is checked in, and abort if it isn't, you'll want to do that before releasing (since releasing usually can't be un-done), so you'll want to write a BeforeRelease plugin.
Almost everything else you'll want to do belongs in AfterRelease: you'll probably want to commit any changes made during the release process (like bumping the "next" placeholder in the Changes file by NextRelease); you might want to tag the release so you can find the responsible commit in the future; you might want to publish your changes to a public location, if you're using a distributed VCS. All of these things should happen after you've successfully released, so you'll want to use the AfterRelease role.
Because you may be putting so many behaviors into AfterRelease, make sure you order them properly! Committing changed files won't help if you're only changing files after that commit. A newly-made release tag won't be visible if you make it after pushing to your public repository. Keep track of your plugin ordering!
If you'd like to learn how the Dist::Zilla build process works, turn to page 14
If you'd like to learn how to manage your version number with Dist::Zilla, turn to page 6