It seems rather fun actually. Especially when doing it for enjoyment. But for now, I think I'll worry about speaking C# first before tackling anything else LOL.
From: [email protected] [mailto:[email protected]] On Behalf Of Parker, Jeff Sent: Thursday, August 18, 2011 3:06 PM To: [email protected] Subject: RE: [ccnet-user] Re: Chicken and egg build dependency Usually the reason we (myself and my fellow developers) go through a build server is because we can't guarantee the developers have the latest versions of our software installed on their machines. The build server always pulls from source control from the latest label in source control, so it should be the most recent version of the code that is built and moved to production. We also run our tests on the build server to double-check to make sure everything still works before we move to the next phase, such as moving the code to production. On another note, while initially working with CruiseControl.NET and MSBuild may seem daunting, through some work on standardizing and making common blocks, it can get much simpler to work with over time. What this means is that while one or more build administrators might have to learn the complex details of the MSBuild and CruiseControl.NET XML languages, in the long run everyone else should benefit from the resulting simpler language that the build administrators will develop. MSBuild and CruiseControl.NET both support the concepts of variables, and CruiseControl.NET supports include files for breaking up the configurations into smaller reusable chunks. These concepts can be used to produce standard build, test, and deploy structures for your projects, and then all developers need to speak is the language of the common standards. Using ourselves as an example, we have gone through the process of automating our build processes, including standardizing how the code is built and tested, including: 1. Build in debug mode 2. Run tests against the debug version, including code coverage analysis 3. Build in release mode 4. Move the code to the location where the software gets installed from When we went through this process, our MSBuild build scripts became highly standardized by using variables, to the point where only 2 variables change between build scripts: 1. The name of the project 2. The name of the project that contains the tests At that point, we were able to templatize the build file as part of a custom project template, so that even these variables are managed automatically when creating the project. As a result, we rarely have to touch the MSBuild build script (only for adjusting what is considered pass-fail for code coverage). We were also able to use the CruiseControl.NET variables and include files in ccnet.config, to standardize the build and deploy process as well, so our CruiseControl.NET configuration became very simple as well. For example, a config section for building one of our projects might look like (just an example): <cc:scope Project="ProjectName" SourceControl="$(BaseSourceControlPath)SourceControlProjectFolder"> <cc:define name="DeployLocation"> <cc:DeployLocation_TestServer /> </cc:define> <cc:BuildTestAndRelease /> </cc:scope> DeployLocation_TestServer and BuildTestAndRelease are include files that contain the standard instructions for building the project, running the tests, rebuilding as a release version, and moving the code to the next phase. Also through the use of include files, we were able to separate the individual builds each into their own files, so not everything was in the ccnet.config - just the variable definitions and the include file references so CruiseControl.NET knew where to read all of the files. To make a long story short, while this seems daunting and overwhelming at first, there is hope - it can be made much simpler and easier to work with in the long run. From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Katherine Moss Sent: Thursday, August 18, 2011 1:31 PM To: [email protected]<mailto:[email protected]> Subject: RE: [ccnet-user] Re: Chicken and egg build dependency Oh. Well maybe I don't yet (probably quite likely), don't understand the full CI concept. Why would you have extra build processes if the F5 key was already pressed from developers working via their local desktops? From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of Michael Powell Sent: Thursday, August 18, 2011 2:25 PM To: [email protected]<mailto:[email protected]> Subject: Re: [ccnet-user] Re: Chicken and egg build dependency In the current context, I believe we're talking about MSBuild as a server-only thing, which CC.NET<http://CC.NET> would kick off. It's nothing that developers would necessarily need from their local desktops, per se. In other words, we would still work through our solutions as per usual. On Thu, Aug 18, 2011 at 11:59 AM, Katherine Moss <[email protected]<mailto:[email protected]>> wrote: I think it comes with the framework. It's hard when development is based on VS 2010 though, not to flip your finger on the F5 key and get your solution built. I'm jus using that at this time in terms of development. -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Brad Stiles Sent: Thursday, August 18, 2011 1:31 PM To: [email protected]<mailto:[email protected]> Subject: Re: [ccnet-user] Re: Chicken and egg build dependency While it's true that Visual Studio uses MSBuild behind the scenes, MSBuild can be installed separately with the .NET Framework. It's been long enough that I don't remember, but it's either included with the framework, or at least some packages, or is available in a separate SDK download. On Thu, Aug 18, 2011 at 12:55 PM, Katherine Moss <[email protected]<mailto:[email protected]>> wrote: > But remember how MSBuild is built into Visual Studio. And it's just > XML like you all should be familiar with. > > > > From: [email protected]<mailto:[email protected]> > [mailto:[email protected]<mailto:[email protected]>] > On Behalf Of Michael Powell > Sent: Thursday, August 18, 2011 12:31 PM > To: [email protected]<mailto:[email protected]> > Subject: Re: [ccnet-user] Re: Chicken and egg build dependency > > > > Sounds like we may be on an MSBuild track anyway. I'm trying to avoid > much of that because that's just one more script we need to become > knowledgable about, but like you said, if it's a matter of licensing > what not, then plausibly we look into the targets and setup our > MSBuild environment for the build. > > On Thu, Aug 18, 2011 at 7:36 AM, Brad Stiles > <[email protected]<mailto:[email protected]>> > wrote: > >> 1. Having it be part of the Svn solution is sufficient for now. >> Minimally, we let the thing travel with the tools part of the project and >> let it be. > > If you're using a standard installation of Visual Studio for your > developers, you shouldn't really need to do this type of thing. > Installing Visual Studio components on a build server *may* require > you to have a Visual Studio license for that server. This *may* be > covered by an appropriate MSDN volume license, but you need to verify > that with your compliance folks. > > Oftimes new Visual Studio project types are supported in MSBuild using > new "targets" files and sometimes additional or modified assemblies. > If you can discern (perhaps using an installation watcher program) > what those changes are, you might be able to make just those > modifications on your build server and eliminate the need to install > either Visual Studio or any addins on the server itself. > >> 2. The setup.exe requires some user interaction anyway. It asks at >> least one or two questions that require end-user input. > > Using the command line can often eliminate the user interaction > entirely. Another option is to modify the MSI file itself to change > the queried values to the ones you want. This requires tools you may > or may not have. > >> 3. This adds a project type to the Visual Studio environment that is >> required by one of the solution's projects. Definitely more than I >> want to get into for any CI configuration concerns. > > If it's solely a matter of additional assemblies, that can usually be > managed by source control, in your case, Subversions svn:externals > capability. If it's a matter of targets in MSBuild build files, then > you have a slightly different problem. Making those changes one time > and forgetting about them is likely to be much easier. > >> All that said, good to know about the <msiexec/> block. > > To be clear, I was talking about using MSIEXEC.EXE, the program to > which msi files are tied in Windows, not anything in NAnt or > CC.NET<http://CC.NET>. > > Brad > >
