That sounds good to me,
We'd need to write the "release" scripts pretty much from scratch anyway
so we might as well do it in RAKE since as you pointed out there's no
need to have it run elsewhere than on the build server.
krzysztof
On 26/04/2011 10:49 PM, Roelof Blom wrote:
IMHO MSBuild is not really suitable for creating nuget, packaging,
releasing to SF etc.
As these tasks are only executed by the TeamCity server and/or
committers rake with Albacore will make this a lot easier and workable.
There are of course ways to get MSBuild to do this (like creating a
nuget package with NuGet.MSBuild
<http://biasecurities.com/blog/2010/creating-nuget-packages-with-teamcity/>)
it's really throwing in more and more XML for no apparent benefit.
A combination of "front-end" MSBuild scripts like we have now and a
"back-end" rake script looks best to me.
This way there's no barrier to open and build our projects locally
like they can now, and the rest can just script and automate anything
that comes to mind with a tool well suited for it.
-- Roelof.
2011/4/25 Krzysztof Koźmic <[email protected]
<mailto:[email protected]>>
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]
<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:castle-project-devel%[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.
