Perl module development - managing branches

[Bill Moseley]

On Fri, Nov 7, 2014 at 1:08 PM, Abigail <abigail at abigail.be> wrote:

> >    - All the modules need to be in @INC -- so we might have to create
> >    symlinks to each  distribution's "lib" directory.
> >    - But, some code is XS or uses share directories.
> >    - Some modules don't exist until "make" is run -- they are created
> when
> >    the module is build.
> >
> > Is this situation familiar to anyone?   Have you found an approach that
> > works well?
> >
>
>
> This sounds very long winded.
>
>
> If I were going to design a workflow, I would start by figuring out
> what you want from the release/rollback process. Start by asking and
> answering questions like:
>

To answer your questions, the goal it to be able to deploy very frequently.
  Downtime is very expensive and is to be avoided.   The plan is to use
Capistrano which deploys with symlinks so rollbacks are "easy".   The goal
is to automate the entire process -- from the load balancer changes, db
updates, and code deploy across multiple data centers.   Release should be
easy.   This part is more understood.

But, the question I have is more related to development and Perl modules.
The issue being when running "git checkout -b feature123" then should use
all the Perl modules in that branch.

Here's the current thought:   Perhaps I'm overlooking a cleaner approach.

Each developer works in their own VM (so all paths can be the same).   Then
put Perlbrew also in Git. That way when someone checks out a branch they
really check out everything.   Modules get added to Perlbrew with "dzil
install" or cpanm and we get rid of our existing, shared, DarkPAN.   Merges
might be get interesting.

Having built files in source control is not a great approach, but seems
like the simplest approach to be able to switch all modules when a
developer change branches in Git.

There are libraries that live outside of Perl, of course, but those change
infrequently and can be managed manually.

Other options we considered is creating a bunch of symlinks to all our
distribution's lib (or blib) library every time we checkout a branch.  Not
very clean, either.





-- 
Bill Moseley
moseley at hank.org