Perl module development - managing branches

[Abigail]

On Fri, Nov 07, 2014 at 11:58:02AM -0800, Bill Moseley wrote:
> I'm looking for ideas to manage our in-house Perl distributions when
> working with different branches.   I'm wondering if anyone here has been
> though this before and has some suggestions.
> 
> We are in the process of moving from Subversion to Git and the plan is to
> make all changes to the code in branches and use pull requests into the
> release Git repo. Similar to "gitflow" workflow.
> 
> What we have been doing up until now is running our own private CPAN
> (DarkPAN) where developers release updated distributions.   For branching
> we have at time used multiple DarkPANs, but that has been rare.   We have
> also looked extensively at Pinto, which is designed specifically for this,
> but so far using multiple DarkPANs has worked when needed.
> 
> Our old process followed the CPAN model.   We had all our Perl
> distributions in svn and once changes were checked in and tested then the
> developer would "release" to our internal DarkPAN.  That would generate a
> new version (using Dist::Zilla) and then code would depend on that version:
>  "use MyCorp::Foo 1.142300;
> 
> The idea, of course, is that the new version of a module is backwards
> compatible.  So, keeping the most recent version in a common DarkPAN was
> fine.    That's not always the case when branching and incorporating code
> at different times.   The root of the problem is we need to have parallel
> branches and version numbers are not branch-aware.
> 
> Our current thought is to throw out version numbers and the idea of
> dependencies.  Each branch would contain ALL our in-house distributions and
> we would build all the distributions and install into Perlbrew at build
> time.     But, then how do developer's work?
> 
> Here's a few sticking points:
> 
>    - 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:

  -  How often do you release/want to release? Weekly? Daily? Multiple
     times a day? As soon as a new feature is done? Whenever the CEO 
     thinks a release needs to be done?
  -  How expensive is downtime during a release? Can you even be down?
  -  How do you release things that aren't written in house? Or non-Perl?
    (CPAN libraries, other libraries, database changes, OS changes, etc)
     In particular, how do you deal with changes that are requirements
     for your upcoming code changes?
  -  How do you plan to handle rollbacks? What's the cost of running with
     bad code?
  -  Do you want/need to ability to do hotfix/emergency patch your
     production code.
  -  How much of your release/rollback process is going to be
     automated/scripted and how much is done manually?



Abigail