On Thursday, 25 May 2017 2:59:47 PM AEST Erik Christiansen via luv-main wrote:
As long as
they're committing their changes regularly to the version
control system,
I had the developers working on individual branches, then performed all
main branch commits myself, after checking that there were no CRLFs or
other nonsense, and that it compiled. Adding a useful version tag and
management-relevant commit message is also best done with an overview.
One large project that I once worked on had an automated build checking system
that would email the developer and their team leader about any potential build
issues with code they checked in. This happened regularly due to conflicting
changes and some limitations of the language and development environment (in
house language that had some deficiencies in some regards but I can't remember
clearly). The standard practice was to work on such issues as soon as you
arrived at work and expect the team leader to ask for a progress report just
before lunch. It wasn't ideal in some ways, but it worked reasonably well.
built-in CI
tools (e.g. you can configure it to automatically try to
compile the software on every commit and report the outcome to the
developer), and more.
Maybe things are different in the embedded world, but I can't remember a
developer submitting code which didn't build - that would be a
professional embarrassment never lived down. And the makefile could
readily support a "make commit", to automate a pre-commit build. I have
to admit to relying on healthy paranoia to ensure I checked that it
built, before the commit.
That depends on the scope of the project. If you have a project where a full
build takes a few hours then developers tend to just compile the bits that
they are working on which has some potential for conflicting commit. If you
have a project with dependencies on external libraries then if the developers
don't all have the same versions of those libraries you can have commits that
don't compile for others.
--
My Main Blog
http://etbe.coker.com.au/
My Documents Blog
http://doc.coker.com.au/