On May 3, 3:46 pm, "Mike Schilling" <mscottschill...@hotmail.com>
wrote:
Joshua Maurice wrote:
Currently ~145 min compile and package, no tests, on the automated
build machine. 188 min more for the standard regression /
acceptance / integration test suite. Some of the tests are
currently distributed across several automated build machines, with
the longest suite at 87 min. Double those times, or thereabouts,
for a lower end developer computer. Any change requires a full
clean build as we no incrementally correct build, and it has not
been componentized into smaller chunks. For example, the
serialization framework implementation changes slightly frequently,
which affects a lot of the code, such as the file persistence,
database persistence, engine, and GUI "components".
Does the serialization framework change often? That would be
horrific, and there's probably nothing to be done to improve the
build cost when it does. But I presume that it changes as the result
of some feature being added, so that can be mitigated by not
checking the change into source control until the feature (or better
yet, set of fesatures) is complete.
I wish I knew. I just got an email today from the serialization team
asking "What's with this error?" I "hacked" the C++ Maven plugin to
report "<> has detected visual studios warning <>, deletion of a
pointer to an incomplete type. This is formally undefined behavior
according to the C++ spec. Fix it." Apparently changes are still
ongoing.
Also, developers are usually good at optimizing their own work. If a
developer is adding new classes or changing implementation rather
than interface, there's no need to recompile the world. Even when
changing interfaces, the developer usually has a good idea of which
bits of the system use those interfaces, and can recompile just
those parts.
As such a developer, perhaps, but when I mess up, I break the mainline
build, and because the build on the automated build machine, or
private perforce branch build machine, can take the better part of a
day, it's sometimes hard to isolate down who broke it, and especially
when ML is broken this leaves people in a bind. Currently we lock ML
on such events. Rollback is possible. Devops is floating that idea
around at the moment.
incorrectly. I'm not suggesting that.
It is. They do a hell of a job (and I don't say that just because I know a
2. Encourage developers to stay isolated, rather than intergating
often and updating other developers' changes often.
Sounds like integration hell. We do have separate teams working on
their own little view for weeks or a month or two on end, and each
team has their own private branch in perforce which is integrated
roughly weekly with mainline.
any merges that result. Though if there's a lot of churn in the code and
3. Do a continuous build that allows developers to grab the most
recent complete, tested code, so they can recompile only the code
they have checked out and the code that depends on it. Throw lots of
hardware at this, so that failures are found early.
Also done.
The problem is that it's not helping. It's way too much code, way too
many tests, taking way too long to build.