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
