Hello Mirko.
I've been there too. With builds that take 4-6 hours to run, hundreds of
modules, and lots of testing failures, some intermittent, some not. In my
case, I had a very tempremental ESB/Process Server's serviceDeploy to
contend with. I added a retry option into the was6:serviceDeploy goal to
deal with just that.
I'll comment along with what you're written below.
On Mon, Apr 13, 2015 at 9:04 PM, Mirko Friedenhagen <mfriedenha...@gmail.com
> wrote:
> Chris,
>
I do wish people would put at least "Hi" or "Hello" in front of it. I
always makes me think that I'm being spoken down too or told off.
>
> it is _my personal_ experience, that running release:perform fails
> more often than the taging/comitting steps in release:prepare.
> - E.g. I run release:prepare and some plugins are only activated when
> performRelease is set (checkstyle, rat, gpg, license-checker).
>
As you say, that all depends on how you run your plugins. I normally
-DskipTests=true into one or the othe (prepare or perform).
> - You may argue that I just should activate the same profiles during
> preparationGoals ("-DperformRelease=true clean verify") and be good.
> - But we have multi-module builds, where tests takes several hours (a
> problem of it's own, I know), so teams are not willing to run tests
> during prepare *and* perform.
>
If you think of the prepare as the SCM operations, and the perform as the
real testing stage, then you've got a good (and I think correct)
separation.
I prefer to run the tests in the perform stage, as they can be re-run. That
is why perform *can* be rerun; it was designed to be.
> - I could advise them to run the tests during prepare only, however
> this feels strange as the binaries are deploy are not the same.
>
And why I don't. The binaries are different? Why?
That aside, running in the perform stage means that you are truly testing
the released binaries, no ifs buts or maybes.
> - So I advise them to skip tests during prepare (you could even set
> preparationGoals=clean).
>
I do.
> - Then you may end with tags which never make it into production as a
> test broke during release:perform.
>
So?
Ignoring the fact that perform can be rerun, you're always going to have
'broken' releases. Whether due to broken code or a testing failure (valid
or intermittent) or not, you're always going to have to contend with the
possibilies of a broken release.
I think that you're pushing too much value onto the current working
definition of what a release is. A release is a release that matches a SCM
tag. That's it. Whether it works or not is yet to be determined. Even *if*
it reaches production, that does not meant that it works. Or should have
gone to production either...
> - While this is no problem, when you only do release builds every
> other day, other teams want to deploy continuously and then you are
>
Well, the fundamental issue here is that of expectations. 4+ hour builds
and continuous deployment are pretty much mutually exclusive here. CD here
is wishful thinking. Oh, in the WebSphere Process Server sense, after a 4+
hour build, the deployments themselves took 2-3 hours (absolute worst case).
In my case, I forced a nightly build. The devs soon learned that things had
to be done by the end of the day or else they would not be in the release.
> left with a lot of non-deployed tags in your SCM after a while (or you
> would need a procurement mechanism of tags which made it into
> production).
>
>
You could equally have a large number of tags that DID make it into
production! Again, so what?
I introduced the concept of a Platform Release, which was a cherry picking
of what versions of what formed a release.
- PortalRelease-X.Y.Z.B - a collection of 3-5 Portal ears/wars.
- WPSRelease-X.Y.Z.B - a collection of 30 odd EARS, and around 30 odd
Testing EARS (Process Server)
- WMBRelease-X.Y.Z.B - a collection of 40+ Message Broker BAR files.
(Message Broker)
etc
Each of the XXXRelease projects was a zip file.
Then I released the PlatformRelease projects (yes, a cascading release
mechanism) that was a zip of zips.
That is the binary bundle that was allowed to be deployed. That was what
all of the CCB's etc approved.
No one really cared about the prior releases, but they were documented
should someone need them.
If they needed easy access, I'd give them a web apge
table/matrix/spreadsheet.
I don't see it as an issue.
Now, back to the point. I don't think messing with the release mechanism is
going to make things any easier, as it's a process issue that you've got to
solve.
I (think I) understand the issues, sizes and timings of what you've
explained above, as it was projects of this size that I've worked with for
the last 6 years.
However, I do not think that doing a retroactive push is actually going to
help, in fact, I think that it's more than likely to complicate matters.
Eg, what happens to duplicate tags on separate repos if someone should
accidently attempt to push them later on? (might be a bad example)
Just my experience.
-Chris
>
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Mon, Apr 13, 2015 at 3:48 AM, Chris Graham <chrisgw...@gmail.com>
> wrote:
> > I'm not actually sure of what problem you're trying to solve here.
> >
> > On Sat, Apr 11, 2015 at 6:49 AM, Mirko Friedenhagen <
> > mfriedenha...@apache.org> wrote:
> >
> >> Hello,
> >>
> >> we now have pushChanges and localCheckout in the release:prepare goal.
> >> IMO pushing commits and tags after a successful release:perform or
> >> release:stage would be a good thing then, as this will probably
> >> succeed most of the times.
> >>
> >>
> > I have a real problem with the word 'probably' here. As there will always
> > be times when that is not the case, when things fail. Sometimes on a
> > permanent basis, sometimes a temporary failure.
> >
> > What appears to be the case here, is that we've come up with a proposed
> > solution to a problem that I have no clear idea about. Can someone please
> > elaborate?
> >
> >
> >
> >> What do you think about something like pushChangesAfterPerform?
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
