Both.  We use it from the command line for local builds and then we also use
it for CI builds on a TeamCity server that we have running up in AWS.

Kelly

On Mon, Apr 25, 2011 at 5:51 PM, Greg Young <[email protected]> wrote:

> Do you use this for local builds or only on ci?
>
>  On 25 Apr 2011 17:21, "Kelly Leahy" <[email protected]> wrote:
> > It might be worth looking at psake (https://github.com/JamesKovacs/psake
> ).
> > These days it's pretty hard to find people that don't have powershell
> > installed, and it's pretty easy to get to the "minimum bar" for psake
> (i.e.
> > understand how to do most things you need). It has a similar philosophy
> to
> > rake, but is much better for .NET projects than rake/ruby (IMHO that is).
> >
> > Wev'e been using it for our projects for a while now and very much like
> it,
> > once we got a bit over the hump on how to do powershell stuff.
> >
> > We use it to:
> > 1) compile/build our projects,
> > 2) deploy to azure
> > 3) manage cleanup of azure storage
> > 4) deploy to local servers
> > 5) run tests
> > 6) invoke selenium + IIS and run our web integration tests
> >
> > plus several other "automation" tasks that we use for day-to-day
> > development.
> >
> > So far, we haven't had a problem that we couldn't solve with it, and have
> > never needed to build "custom code" for it, except in those cases where
> > doing something in Powershell was just not the best solution (so we built
> a
> > command line 'devtool' that does much of the work, similar to svcutil.exe
> > from MS or other similar tools).
> >
> > Just my $0.02
> >
> > Kelly
> >
> > 2011/4/25 Henry Conceição <[email protected]>
> >
> >> Hi Henrik,
> >>
> >> I'm not reluctant to give you access. As I did explain to you, only
> >> committers have access to the Castle's git, teamcity and stuff. You
> >> can see this as bureaucracy, but having this more hardened policies
> >> protects the project from fly by night contributors and privileges
> >> meritocracy.
> >>
> >> Cheers,
> >> Henry Conceição
> >>
> >>
> >>
> >> On Mon, Apr 25, 2011 at 11:08 AM, Henrik <[email protected]> wrote:
> >> > I have worked a lot with MSBuild in my professional projects and I
> >> > have the firm opinion that XML is not a programming language, and
> >> > should hence not be used like it is. By saying that exec is the way
> >> > out of the mess is to completely discard any remaining credibility of
> >> > the build tool.
> >> >
> >> > Build tools do dirty-checking, cleaning, clobbering, dependency
> >> > checking, parallelization, status tracking and much more. MSBuild is
> >> > in my opinion too verbose and hard to use -- and this is after
> >> > spending a lot of time with it and knowing its ins and outs.
> >> >
> >> > Rake/Ruby is extensible at its core and has a lot of momentum in the
> >> > remaining ALT.Net circles.
> >> >
> >> > The way I have set up the build scripts; if you read the code; is in a
> >> > way that makes it possible to have team-city recognize and do all the
> >> > things you mention. I have experience with TeamCity and rake from
> >> > other projects as well and I have asked Henry to get access so that I
> >> > can set it up, but he's reluctant to give me any rights to solve the
> >> > problem.
> >> >
> >> >
> >> > On Apr 25, 12:13 pm, Krzysztof Koźmic <[email protected]>
> >> > wrote:
> >> >> I haven't looked beyond putting Nuget package for Windsor 2.5.3 out,
> >> >> something that was frequently requested.
> >> >>
> >> >> I would *love* to have the release process automated (to a point
> where I
> >> >> git push to a new tag and our TeamCity recognizes that, and runs a
> >> >> release build that does everything, including release packaging,
> >> >> releasing to SF, nuget and OW, branching (if new branch is needed,
> that
> >> >> is it's not a point point release and few other things I forgot, like
> >> >> updating the website in all 3 places.))
> >> >>
> >> >> I *strongly* prefer giving MsBuild a fair shot before trying any
> other
> >> >> build solution, mostly because MsBuild is out of the box, it's .NET
> and
> >> >> many developers will flat refuse to install Ruby in order to build a
> >> >> .NET project.
> >> >>
> >> >> I think the scripts we have are really well and cleanly written and
> >> >> while I'm nowhere near as proficient at working with them as Roelof
> is,
> >> >> I've been able to tweak them on several occasions, same as I'm sure
> >> >> everyone else on the team would be.
> >> >>
> >> >> This however reminds me of another problem I've had, and we'll
> continue
> >> >> having, that is keeping consistency in build scripts among projects.
> >> >> I've mostly worked with Core and Windsor and all changes and tweaks
> >> >> introduced in one project had to be manually copied to the other one.
> As
> >> >> we have many more projects I'm sure trying to deploy changes to build
> >> >> process all across the board would be nothing short of a nightmare.
> >> >>
> >> >> Can we please consider some options for automated sharing the build
> >> >> files among all of our projects so that we only change things once
> and
> >> >> that change gets propagated to every project?
> >> >>
> >> >> I think it might also be beneficial to have a wiki page that
> >> >> a) documents how our build works and how it should be used
> >> >> b) documents customizations we've made to .csproj files so that it's
> >> >> easy to add a new project and get it to work with the build
> >> >>
> >> >> Krzysztof
> >> >>
> >> >> On 25/04/2011 7:49 PM, John Simons wrote:
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> > I would much rather use rake then msbulid.
> >> >> > No offence to Roelof but currently I think the only person that can
> >> >> > maintain those scripts is him and I don't believe this is a good
> >> >> > situation. I think Krzysztof is trying to hook up nuget and ow to
> our
> >> >> > build + automate most of it, how is that going? Is msbuild working
> for
> >> >> > this?
> >> >>
> >> >> > Cheers, John
> >> >>
> >> >> > On 25/04/2011, at 5:36, Henry Conceição <[email protected]
> >> >> > <mailto:[email protected]>> wrote:
> >> >>
> >> >> >> About the build: I don't like the ideia of obligating everyone to
> >> have
> >> >> >> ruby + rake in order to build the tx stuff. Probably we will
> restore
> >> >> >> the msbuild and get rid of the rake scripts when we merge the
> changes
> >> >> >> on the master repo.
> >> >>
> >> >> >> On the 3.5 matter: At least for me, we can drop de support for it.
> >> >>
> >> >> >> Cheers,
> >> >> >> Henry Conceição
> >> >>
> >> >> >> On Sat, Apr 23, 2011 at 12:44 PM, Henrik Feldt <[email protected]
> >> >> >> <mailto:[email protected]>> wrote:
> >> >> >>> Yup, a merge it is. They are merged in my repository now.
> >> >>
> >> >> >>> The rest in this letter is about the upcoming alpha.
> >> >>
> >> >> >>> Docs:
> >> >>
> >> >> >>> I have added docs to the wiki as well on my repo.
> >> >>
> >> >> >>> Building:
> >> >>
> >> >> >>> Both projects have been rewritten, based on the previous ideas.
> This
> >> >> >>> includes using rake for the build – using it makes me about 10
> times
> >> as
> >> >> >>> productive when writing the scripts.
> >> >>
> >> >> >>> Versioning:
> >> >>
> >> >> >>> In the rake scripts I have set up build-number versioning like
> that
> >> >> >>> NHibernate uses, so that
> >> >>
> >> >> >>> 100x is alpha
> >> >>
> >> >> >>> 200x is beta
> >> >>
> >> >> >>> 300x is rc
> >> >>
> >> >> >>> 4000 is ga.
> >> >>
> >> >> >>> So e.g., currently I’m building 2.9.9.11215 at 3 pm, or
> 2.9.9.1001
> >> >> >>> for the
> >> >> >>> first alpha.
> >> >>
> >> >> >>> The versioning for private builds uses the day of the year and
> the
> >> >> >>> hour as
> >> >> >>> the build number.
> >> >>
> >> >> >>> Sadly:
> >> >>
> >> >> >>> Right now I’m just working against .Net v4.0. There’s no real
> >> problem
> >> >> >>> re-targeting 3.5.
> >> >>
> >> >> >>> Code contracts:
> >> >>
> >> >> >>> I’ve done both with MS code contracts for good or bad, but only
> >> >> >>> debug builds
> >> >> >>> have the contracts. In my opinion it’s nice for showing intent
> >> around
> >> >> >>> interfaces. The most prominently used part is that of the static
> >> >> >>> verification, the part which doesn’t compile into the assembly. I
> >> >> >>> believe
> >> >> >>> they work very well with unit tests as well, as one only tests
> >> allowed
> >> >> >>> functionality as opposed to disallowed functionality that throws
> >> >> >>> exception.
> >> >>
> >> >> >>> People use the debug build with contract assertions or the
> release
> >> build
> >> >> >>> without any alterations.
> >> >>
> >> >> >>> Alpha TODO:
> >> >>
> >> >> >>> Finish build script for building nuspecs with lib and tools.
> Perhaps
> >> a
> >> >> >>> transform file for adding AutoTx and the new NHibernate Facility
> to
> >> >> >>> a web
> >> >> >>> site. Test this out and release 2.9.9 (perhaps). Set up a build
> >> >> >>> server for
> >> >> >>> the new rake scripts. Does castle have one that I can use for
> >> testing –
> >> >> >>> TeamCity? I can create its configs.
> >> >>
> >> >> >>> Release 3.0 TODO File Transactions:
> >> >>
> >> >> >>> I’m aiming to spend a few hours on the file transactions before
> >> >> >>> release to
> >> >> >>> fully integrate it with ITxManager, but the non-file transaction
> >> >> >>> parts seem
> >> >> >>> OK.
> >> >>
> >> >> >>> Release 3.0 TODO Forking:
> >> >>
> >> >> >>> There is also a bit of problems related to continuation passing
> when
> >> >> >>> forking
> >> >> >>> dependent transactions through the new [Transaction(Fork=true)]
> >> >> >>> functionality as tasks are awaited on the finalizer thread if
> >> >> >>> exceptions are
> >> >> >>> not observed on the main thread.
> >> >>
> >> >> >>> Release 3.1 TODO Retry policies etc:
> >> >>
> >> >> >>> This idea is something I’d like to investigate: possibly retrying
> >> failed
> >> >> >>> transactions through the transaction interceptor. Also, creating
> a
> >> >> >>> IHandlerSelector for choosing transient lifestyle components if
> in
> >> no
> >> >> >>> ambient transaction.
> >> >>
> >> >> >>> Cheers
> >> >>
> >> >> >>> Henrik
> >> >>
> >> >> >>> From: [email protected]
> >> >> >>> <mailto:[email protected]>
> >> >> >>> [mailto:[email protected]] On Behalf Of
> >> >> >>> Krzysztof Kozmic
> >> >> >>> Sent: den 15 november 2010 02:30
> >> >> >>> To: [email protected]
> >> >> >>> <mailto:[email protected]>
> >> >> >>> Subject: Re: Castle.Services.Transaction + Castle.Windsor?
> >> >>
> >> >> >>> Henrik,
> >> >>
> >> >> >>> What's the status of this? Did you go ahead with the merge? Do
> you
> >> still
> >> >> >>> plan to?
> >> >>
> >> >> >>> From another department - would you care to have a look at the
> >> >> >>> documentation
> >> >> >>> and expand it to fully cover all functionality of the facility?
> >> >> >>>http://stw.castleproject.org/Windsor.ATM-Facility.ashx
> >> >>
> >> >> >>> Krzysztof
> >> >>
> >> >> >>> On 23/09/2010 8:52 PM, Henrik Feldt wrote:
> >> >>
> >> >> >>> Hello everyone,
> >> >>
> >> >> >>> I’m considering merging the code of Castle.Services.Transaction
> with
> >> >> >>> Castle.Facilities.AutomaticTransactionManagement/AutoTX. This
> would
> >> >> >>> introduce a dependency on Castle.Windsor for
> >> >> >>> Castle.Services.Transaction.
> >> >> >>> (Another way of saying it is that the IoC-container would be
> >> >> >>> required for
> >> >> >>> using the transactions project, which it is not now. However, it
> >> could
> >> >> >>> simplify versioning/dll-management slightly).
> >> >>
> >> >> >>> As of now it is merely a thought: please tell me what your
> opinions
> >> >> >>> are on
> >> >> >>> whether to merge them or not!
> >> >>
> >> >> >>> Kind regards,
> >> >>
> >> >> >>> Henrik
> >> >>
> >> >> >>> --
> >> >> >>> You received this message because you are subscribed to the
> Google
> >> >> >>> Groups
> >> >> >>> "Castle Project Users" group.
> >> >> >>> To post to this group, send email to
> >> >> >>> [email protected]
> >> >> >>> <mailto:[email protected]>.
> >> >> >>> To unsubscribe from this group, send email to
> >> >> >>> [email protected]
> >> >> >>> <mailto:[email protected]>.
> >> >> >>> For more options, visit this group at
> >> >> >>>http://groups.google.com/group/castle-project-users?hl=en.
> >> >>
> >> >> >>> --
> >> >> >>> You received this message because you are subscribed to the
> Google
> >> >> >>> Groups
> >> >> >>> "Castle Project Users" group.
> >> >> >>> To post to this group, send email to
> >> >> >>> [email protected]
> >> >> >>> <mailto:[email protected]>.
> >> >> >>> To unsubscribe from this group, send email to
> >> >> >>> [email protected]
> >> >> >>> <mailto:[email protected]>.
> >> >> >>> For more options, visit this group at
> >> >> >>>http://groups.google.com/group/castle-project-users?hl=en.
> >> >>
> >> >> >>> --
> >> >> >>> You received this message because you are subscribed to the
> Google
> >> >> >>> Groups
> >> >> >>> "Castle Project Development List" group.
> >> >> >>> To post to this group, send email to
> >> >> >>> [email protected]
> >> >> >>> <mailto:[email protected]>.
> >> >> >>> To unsubscribe from this group, send email to
> >> >> >>> [email protected]
> >> >> >>> <mailto:[email protected]>.
> >> >> >>> For more options, visit this group at
> >> >> >>>http://groups.google.com/group/castle-project-devel?hl=en.
> >> >>
> >> >> >> --
> >> >> >> You received this message because you are subscribed to the Google
> >> >> >> Groups "Castle Project Development List" group.
> >> >> >> To post to this group, send email to
> >> >> >> [email protected]
> >> >> >> <mailto:[email protected]>.
> >> >> >> To unsubscribe from this group, send email to
> >> >> >> [email protected]
> >> >> >> <mailto:[email protected]>.
> >> >> >> For more options, visit this group at
> >> >> >>http://groups.google.com/group/castle-project-devel?hl=en.
> >> >>
> >> >> > --
> >> >> > You received this message because you are subscribed to the Google
> >> >> > Groups "Castle Project Development List" group.
> >> >> > To post to this group, send email to
> >> >> > [email protected].
> >> >> > To unsubscribe from this group, send email to
> >> >> > [email protected].
> >> >> > For more options, visit this group at
> >> >> >http://groups.google.com/group/castle-project-devel?hl=en.
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> Groups
> >> "Castle Project Development List" group.
> >> > To post to this group, send email to
> >> [email protected].
> >> > To unsubscribe from this group, send email to
> >> [email protected].
> >> > For more options, visit this group at
> >> http://groups.google.com/group/castle-project-devel?hl=en.
> >> >
> >> >
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "Castle Project Development List" group.
> >> To post to this group, send email to
> [email protected]
> >> .
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group at
> >> http://groups.google.com/group/castle-project-devel?hl=en.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> > To post to this group, send email to
> [email protected].
> > To unsubscribe from this group, send email to
> [email protected].
> > For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
> >
>
>   --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Development List" group.
> To post to this group, send email to [email protected]
> .
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Castle Project Development List" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/castle-project-devel?hl=en.

Reply via email to