On Mon, Feb 6, 2017 at 2:01 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> >
> > PS: I just wish AMBER has continuous integration (again) so I can capture
> > all possible install failures quickly.
>
> We had it - it was working - nobody bothered to use it, support it's use
> or help with it - ergo it died.
>
The Cruise Control was good as an early POC, but it was never advanced to
the point of being truly useful in the devops process. Qualities of an
effective continuous integration platform *require* its use. At a bare
minimum, it should email the offending committer when a build is broken.
But to be truly effective at maintaining quality control, it needs to block
merging to master until all scheduled builds and tests pass. As in the
merge button needs to be greyed-out and not clickable until the build and
tests finish and report that it passes the check. If CI is not at least
mildly irritating to developers, it's not effective. It was also
retroactive, not proactive (it could tell you after you broke master, but
would do nothing to prevent you from doing so).
The projects I've seen that have an "effective CI" almost never introduce
regressions that either break the build or an existing test. And projects
that have *switched* to this model (e.g., cpptraj and ParmEd) showed
improvements (BIGLY): development pace picked up markedly and the
introduction of testing regressions slowed to a crawl.
The reason that Hai, Dan and myself switched to developing on GitHub isn't
because it's the hip thing to do. We do it partially because we get more
attention and community assistance on our codes, but just as importantly,
CI is very easy and effective there.
All the best,
Jason
--
Jason M. Swails
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 06 2017 - 12:30:02 PST
