<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 7:35 AM, Dermot <span dir="ltr"><<a href="mailto:paikkos@gmail.com" target="_blank">paikkos@gmail.com</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>I want to caution you, in the nicest possible way. Writing software requires a number of skills and a lot of research and learning. You can't avoid the latter. What may seem like a lot of unnecessary aggravation (testing and version control) have come about because it's no fun fixing problems after the event.<br></div></div></blockquote><div><br></div><div>Very true.</div><div><br></div><div>Andrew, there's an overwhelming amount of reading on this topic. If you think there's <i>any</i> chance that your app will grow in usage and developers over time then it's well worth planning ahead. Automate <i>everything</i> from the start. It's critical to make deployments fast, repeatable, and dead simple. Probably should also include "scalable" there as a good buzzword.</div><div><br></div><div>Here's a few random links to get you thinking:</div><div><br></div><div><a href="http://12factor.net/">http://12factor.net/</a><br></div><div><a href="https://zachholman.com/posts/deploying-software">https://zachholman.com/posts/deploying-software</a><br></div><div><a href="https://guides.github.com/introduction/flow/">https://guides.github.com/introduction/flow/</a> (we do a modified version of this)<br></div><div><br></div><div>The bottom line is you want to be spending your energy on the application functionality and not on deploying and running the application -- which seems to consume time exponentially if not careful.</div><div><br></div><div><br></div><div>To be honest we have not really found a perfect way of managing Perl dependencies. I think the standard Perl module versioning system falls apart when there's lots of developers, many "apps" involved, and a version control system. Our single app turned into many Catalyst apps that (with the goal of) have "thin" controllers and many models. Those models were originally separate Dist::Zilla Perl distributions in our local DarkPAN. As those were updated with new version numbers the apps were also updated to depended on those. This breaks down when using Git and heavy use of branches because versions are no longer linear -- instead small features and fixes are merged individually.</div><div><br></div><div>We have swung quite far the other way now and moving toward separate repos for each "app" and even copying the same module into multiple repos to promote decoupling (and the cost of code duplication). We are also using Carton to lock down versions and bundle dependencies.</div><div><br></div><div>We have also put Perlbrew into Git with mixed results. I'm not a big fan of placing build artifacts into Git, but having the entire app in a single repo does have benefits. </div><div><br></div><div>We would like to get to a CI pipeline that generates a Docker container and use that for all non-dev deployments. You never know when you will need to deploy <a href="https://www.hashicorp.com/c1m.html">a million containers</a>...</div><div><br></div><div><br></div></div><div><br></div>-- <br><div class="gmail_signature">Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a></div>
</div></div>