Thanks for the reply and I agree with your use of the technologies (and totally understood the work/family/etc time juggle!) due to needs, constraints, etc. Let me briefly explain how we are using, due to our specific needs: for our build system/server, we use CCNet and MSBuild (not Visual Studio) as the fundamental technologies for building (we use other tools like NUnit, WATIN, FxCop, etc, as well), for the same reason you use CCNet and NAnt: the flexibility it provides. Though there are other significant reasons we do not build using a .sln file in our build system/server, one big reason we do not is because of the inflexibility and "black box" view it limits us to.
Thanks, Paul On Jun 22, 4:06 am, Craig <[email protected]> wrote: > HiOgaz, > > I can put in a quick comment from the CC.NET developers - we use a > build script (Nant) for building CC.NET. Basically, there are three > reasons we use this approach: > 1) It provides a lot more functionality than just building the > projects > 2) It is cross platform (we also use it for building CC.NET on Mono) > 3) It doesn't require installing VS on the build machine > > From a personal approach, I also use build scripts at my work. Using > VS to build the final solution is just too limited, especially > considering all the other things that go into producing a good > software product. The only time I would use VS for building is during > development (i.e. on my machine), I never use it on the build server. > > And of course, as a final note, one of the goals we have with CC.NET > is providing complete flexibility. We don't try to constrain people to > develop in certain ways (i.e. VS vs. build scripts). Unfortunately, > the trade off is CC.NET is a bit more complex to configure than some > of the other alternatives. > > And sorry for the late reply, it's getting harder to juggle family, > work and open source stuff. > > Craig > > On Jun 20, 5:15 am,ogaz<[email protected]> wrote:> I have appreciated the > comments on this thread. Thank you. > > > The one fundamental, simple requirement of a good build system, IMO, > > is easy understanding (by developers, not just a "build master", > > "build engineer", "build group", etc, and not via some tribal/group > > knowledge or required translation) of why a build is broken. This > > alone, IMO, is a huge reason for building with project files. > > Investment of time into building a good build system will pay off > > exponentially; a goal should be ease for the developers at the expense > > of the build system creation, not ease of the creation of the build > > system at the expense of ease for the developers. > > > All this said, I have to say that the conclusion for me, at least, is > > "to each is own", depending on needs, constraints, requirements, etc. > > There are some points made that I would think most of us understand - > > they are a given (e.g. not having static paths) - but we live in a > > real world, with real conditions and real problems. I was hoping to > > learn something new, something that would undoubtedly sway me to build > > using the solution file instead of project files, but I have not. > > > Though I wish I would've heard from more people than just the very few > > (three?) that did appreciatively take the time to reply, with more > > varying degrees of experience, I very much appreciate the replies on > > this thread. > > > Thanks! > > > On May 8, 11:12 pm, Sam Calder <[email protected]> wrote: > > > > To clarify, I was talking about building solutions via CCNET. > > > > * Build breakages should be the exception, rather than the rule. You CAN > > > see > > > what broke via the dashboard - look at the build log, see what files were > > > checked in since the last successful build, etc. Sure it takes more than > > > one > > > single click, but its not a regular occurrence so no excuse for being > > > lazy. > > > Plus you can easily see the actual build error messages, same ones as you > > > get in VisualStudio, even get them emailed around... and if you set your > > > build environment up properly it'll be pretty easy to figure out what any > > > build-breaking problem is. > > > * The solution file is just as much a part of the source code as any other > > > file, and ought to be in source control too. Therefore, yes developers > > > should be expected to use the same solution file as each other AND the > > > autobuild. Sure you can change the file for whatever reasons you need > > > (debugging, moving projects, whatever)... but as with any other file, good > > > development practice dictates that you never check in any build-breaking > > > change. If your team all update before committing, then you'll probably > > > find > > > that collisions are rare, and even then they can be resolved just like a > > > collision in any other file. And if you find that you are constantly > > > tripping over each other's solution file changes then frankly it sounds > > > like > > > your project structure is a mess and you've got bigger problems than just > > > your build process. > > > * Regarding unit testing: Our developers hardly ever run unit tests > > > locally, > > > the build process does it all for them (they're getting lazy!!!). Adding > > > new > > > unit tests or unit test assemblies also doesn't require changes to your > > > build config - again if you set it up right, CCNET really can be a low > > > maintenance 'fire-and-forget' build process. If you are testing internal > > > methods then it is no longer a unit test - and the majority of TDD > > > practitioners see it as somewhere between 'a waste of effort' and 'bad > > > practice'. Even if you must do it, there are still ways of doing it from a > > > separate assembly ('InternalsVisibleTo' attribute, reflection with > > > appropriate flags, etc... Google is your friend). And for your sake, I > > > really hope you are not compiling your unit test code into the same DLLs > > > you > > > are releasing! > > > * I've yet to come across any situation where components required for the > > > deliverable were also required (a) not to be in source control and (b) not > > > to be available for the developers. API documentation can be built > > > dynamically. Images can be embedded as resources. Config file can and > > > should > > > be controlled with good serialization practices. And most other > > > application > > > 'content' usually winds up coming out of a database of some sort, > > > regardless > > > of whether its a web app or forms app. Why you would ever want to prevent > > > your developers from accessing X (where X is an integral part of the > > > deliverable they are developing) and still expect to include X in the > > > deliverable and have it function correctly is a mystery. Either you work > > > for > > > the NSA, or you have some serious trust issues in your workplace... and > > > given you're coding in .Net, I highly doubt it's the former. > > > * Obfuscation, encryption, licencing etc. can all be automated if you take > > > the time to figure out how to do it properly. Eg. we encrypt all our > > > database connection strings in the config files, so the production user > > > password is never stored in plain text. > > > * A build is a build, and the same build should go through the same > > > process > > > whether run manually on a developers machine or automatically on a CCNET > > > server, and produce the same result. If it is not possible for your > > > developers to do a full local build then it is not possible for them to > > > tell > > > whether they have broken anything. Take a look at the bigger picture and > > > you'll realise your entire output is nothing but deliverable logic anyway. > > > That includes pre-and postbuild events too... by the way, these are stored > > > in the project file not the solution file, so regardless of your opinion > > > of > > > them, they have no bearing on the discussion of whether to take a > > > project-based or solution-based approach to your build process. > > > > Solution files can be a very useful tool in a well-designed build > > > environment. Much like a nailgun - if used correctly you can you can > > > build a > > > whole house much faster and with less effort. If used incorrectly, of > > > course > > > you can nail your own feet to the floor too. > > > > Disclosure: I wear both hats - developer, and the sole buildmaster of a > > > continuous integration server farm working on over a million lines of code > > > for a billion dollar branch of a Fortune 100 company. On average I spend > > > maybe 1-2 hours per week (total) doing "buildmaster" work: maintaining > > > build > > > processes & environments across all the various development projects in > > > the > > > server farm. The rest of the time I can actually spend doing "developer" > > > work, on my own development projects. To date nobody else has ever had to > > > modify any of our build processes (although they could if they wanted > > > to). I > > > could not achieve this level of productivity without the flexibility of > > > solution files! > > > > (and of course many congrats to the CCNET dev team, for having a product > > > stable and flexible enough to be deployed within at least one Fortune 100 > > > company!) > > > > Cheers, > > > > - Sam. > > > > On Fri, May 8, 2009 at 6:32 PM,ogaz<[email protected]> wrote: > > > > > All - thank you for your responses. I really appreciate the > > > > perspectives and insight. > > > > > Based on some of the responses I should re-clarify that I'm not asking > > > > about how best to build projects within Visual Studio, but asking what > > > > is best when building projects via CCNet (i.e. automated builds and > > > > continuous integration). It is a given that using .sln files when > > > > building within Visual Studio is the logical and best choice. > > > > > If one builds with a solution file then when it breaks, one would only > > > > see (using ccnet web dashboard or cctray) that the solution broke and > > > > not which actual project broke. This can be rather uncomfortable for > > > > debugging if there are many projects in the solution. Also, doesn't > > > > this go against the benefits of having an automated build system, that > > > > is, so that we can what code is working and what code is not working? > > > > If we just use a big, all-inclusive green-light/red-light approach, we > > > > lose out on useful feedback that the build system can (and should, > > > > IMO) provide. > > > > > Generally speaking, we cannot presume that there would be a > > > > single .sln file that all developers would use, so that would go > > > > against the reason for the build process to use the same .sln file > > > > that is being used by the developers. Developers sometimes move > > > > things around in a solution for debugging purposes, with an example of > > > > this being when a developer changes to use a project reference (and > > > > includes the project into the solution) instead of an assembly. > > > > Because of this, developers don't always use the same exact .sln file > > > > or, if they do, there can be frustration amongst developers because > > > > the .sln file is being changed between them. > > > > > As far as having to go through the trouble of having to add a new > > > > project to the build script when a new one is created, this also only > > > > takes a small bit of time and the need for the project would be caught > > > > either when the build breaks and/or when testing occurs. This is just > > > > a simple maintenance task and would be required anyway for any new > > > > unit tests that would need to be added and executed as well. > > > > > To rely on developers running unit tests is unfortunately urealistic. > > > > We all know that developers running unit tests is the ideal situation > > > > but doesn't always happen (and in some shops/teams/groups, does not > > > > happen at all); this is why automated unit tests are implemented in > > > > build scripts, is it not? That being said, the unit tests then need > > > > to occur after a project builds which works with building per > > > > project. I agree that ideally unit tests should be in their own > > > > separate project, but that is not always the case (e.g. testing > > > > internal methods). IMO, unit tests should also be written with the > > > > smallest scope possible, when possible, and that would mean that they > > > > can be project-based; thus, > > > ... > > > read more »
