I start with Module::Starter and then i immediately cd into the distro and initialize a local git repository and check in the code. Then i make my initial customization configuration changes and check those in. Then i hope on over to GitHub and set up a project and then i push my code to that project. Now i can work on any computer that i have registered my ssh keys with Github and push and pull accordingly. Most places of work have internal implementations of Github these days (like Stash or Gitlab) so security/IP issues should not be a blocker.

My development process is very much test driven. I do not add features without testing them. I also make sure my tests run in a very very short amount of time. Less than 10 seconds is my usual goal. I keep my tests simple and explicit, rarely using Object Oriented frameworks unless i really do have a lot of start up and tear down concerns. I never check in code unless all tests pass. If a feature changes then i make sure the tests are changed to reflect the new requirement(s).

Within Github i set up a travis-ci config file and i use travis to smoke test my CPAN module with 6 versions of Perl. Every push to the Github master triggers a new build at travis-ci. I also have my own Jenkins server running and i use that to build, test and create the tardist candidate to be uploaded to PAUSE. From here, i use perlbrew and cpanm to install and uninstall that candidate tardist for a final verification that it is ready to be promoted to "production." Perlbrew allows me to manage multiple versions of Perl locally, so i can easily smoke test by hand if CPANTS hands me back an unexpected failure report (usually days after the upload). Finally, i upload the built asset from my Jenkins server to PAUSE and the bump the version.

Jenkins saves all my successful builds and shows off the tests results thanks to help from TAP::Formatter::JUnit. I do not use a VM for this process because there is no need to. I would use a VM if i needed to build a server to provide a service, not to develop my code. If your current CPAN dependency chain takes 2 hours just to build, doesn't that mean that a client wanting to use your CPAN module will have to wait the same amount of time? You could always build an image of the "base" with something like Packer and use that to develop/test your code with as well. Many businesses are doing that currently because their build times are extremely lengthy.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)