Hi
we always welcom new patches, certainly for new functionality. I myself also use CCNet for other jobs than just 'CI', Wat version of CCNet is your 'hack' based on, because from version 1.5 (current trunk) there are major changes done : adding security, updating the dashboard, mono compatible, .... you can read where I use CCNet for at my blog : http://rubenwillems.blogspot.com/2009/02/ci-continous-installation.html with kind regards Ruben Willems On Fri, May 8, 2009 at 4:30 PM, MKCline <[email protected]> wrote: > > I have used CruiseControl.NET for quite a while and really appreciate > all of the work that has been done. I realize that the purpose is > 'continuous integration' but I have stretched the product into a > different area and was curious what other people's thoughts/processes > around this are. > > Environment -- > Subversion Source Control > .NET Development (primarily ASP.NET Web / Winform Click-Once / > Microsoft Reporting Services) > 5 Environments -- Local Development, Development Server, Test Server, > UAT Server, PROD Server > Developer have rights through Test but another department has to do > all migrations/changes in UAT and PROD to comply with SOX controls. > > The standard is that the developer develops code on their local > machine and commits it to source control. Part of this 'development' > includes msbuild files for all of their application components. A > consistent structure is enforced so that at the root of the > 'Application' there is a 'properties' file that contains any > environment-specific settings (connection strings, server paths, etc) > > I use some base templates and then msbuild actually generates all of > my CC.NET project files based on these templates and the information > that is stored in the msbuild files. > > I have 'hacked' the dashboard to allow some user input via drop- > downs. For each 'component' I have 5 different builds: > Compile -- The typical continuous integration build > Compile and DEV Deploy -- Do everything AND put output on the DEV > server > Create Tag -- This compiles the project and creates a tag in our > source control system of the source code. We then have a separate > 'repository' where we published a versioned binary package > Binary Deploy -- This takes the 'binary package' created by the > 'Create Tag' build and allows it to be deployed to an environment (DEV/ > TST/UAT/PRD) > Create Branch -- Creates a branch of previously tagged source for > 'post-release' modifications > > We have one CruiseControl server, and developers use it to do all of > the work until they are ready to go to UAT. At this point someone in > the other group runs an instance of CruiseControl with permissions to > deploy to UAT. They use the same interface, do a binary deploy of a > specific version and we have a controlled push to the UAT or > PRODUCTION environment, eliminating the manual mistakes that cause > many headaches. > > As I said, my approach was somewhat of a 'hack' to abuse a really good > tool that I knew could handle the job. Just wondering what other > people are doing out there, or if there is a place for a complimentary > set of plugins to CruiseControl to extend it beyond development. >
