Oh, it is fun. But it also earns a living. I can't believe they pay me for this...
On Thu, Aug 18, 2011 at 1:50 PM, Katherine Moss <[email protected]>wrote: > 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]] *On > Behalf Of *Katherine Moss > *Sent:* Thursday, August 18, 2011 1:31 PM > *To:* [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]] *On > Behalf Of *Michael Powell > *Sent:* Thursday, August 18, 2011 2:25 PM > *To:* [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 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]> 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]] On > Behalf Of Brad Stiles > Sent: Thursday, August 18, 2011 1:31 PM > To: [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]> 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]] > > On Behalf Of Michael Powell > > Sent: Thursday, August 18, 2011 12:31 PM > > To: [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]> > > 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. > > > > Brad > > > >**** > > ** ** >
