On tagging, lifecycle management

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

On tagging, lifecycle management

jason marshall-2
I found some references in the various documentation and reviews of
Hudson that implied that there was a way to 1) tag builds in the
source repository, and 2) 'promote' builds.

Unfortunately I can't find any evidence of either in the Hudson UI.
Are these features that are no longer or not yet in the 1.64 build?
Both of these are of high interest to me, and I think also to the team
I work on.




I did find one bug report filed about tagging builds:

https://hudson.dev.java.net/issues/show_bug.cgi?id=51

This was closed as wontfix, with a challenge issued to the bug
originator to look deep in his heart and ask if that's what he really
wanted.


Well, I'm here to say that that's what I really wanted.


Continuous Integration tools should have two high-level goals:

1) Smoothing out issues of code sharing between peers on a software project.
2) Smoothing out issues of transitioning code into Acceptance Testing

Open source projects tend to blur the lines between these two groups
(your users are your peers, after a fashion), but where CI tools
really shine is in bringing some much-needed sanity to enterprise and
commercial software development.  In these environments, tagging of
each 'good' build is not just a neat idea, it's frequently necessary
in order to have frank and honest conversations about what behaviors
are to be expected in which versions of the code.

Some people simply make tagging, versioning and promoting part of
their process (especially if they happen to have someone as a
Configuration Manager), but I've found it to be far simpler to have
the tools automate these particular steps as much as possible, if for
no other reason than it's another source for human error where no
human intervention is really needed.  (Was that supposed to be build
246, or 247?)

Could we perhaps have issue #51 reopened?

Thanks,
Jason Marshall

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Vladimir Sizikov
Hi Jason,

There was a discussion about builds "promotions" recently, and I filed
a FEATURE #141 for this problem, and currently (in my spare time)
trying to come up with Hudson plugin that provides this functionality.

https://hudson.dev.java.net/issues/show_bug.cgi?id=141

So I wonder, what do _you_ mean by "promotion" and could you please
provide a use case for the feature, how do you see it should work?

As for the second topic you've mentioned, tagging, I'm kind of with
Kohsuke on this one, and currently don't see a good benefit of tagging
every build. I guess, I miss some of the subtleties of your
environment and your process, so if you could describe it in more
detail, that would be great.

Thanks,
  --Vladimir

--
Vladimir Sizikov
Sun Microsystems                   [hidden email]


On Wed, Nov 29, 2006 at 01:17:16PM -0800, jason marshall wrote:

> I found some references in the various documentation and reviews of
> Hudson that implied that there was a way to 1) tag builds in the
> source repository, and 2) 'promote' builds.
>
> Unfortunately I can't find any evidence of either in the Hudson UI.
> Are these features that are no longer or not yet in the 1.64 build?
> Both of these are of high interest to me, and I think also to the team
> I work on.
>
>
>
>
> I did find one bug report filed about tagging builds:
>
> https://hudson.dev.java.net/issues/show_bug.cgi?id=51
>
> This was closed as wontfix, with a challenge issued to the bug
> originator to look deep in his heart and ask if that's what he really
> wanted.
>
>
> Well, I'm here to say that that's what I really wanted.
>
>
> Continuous Integration tools should have two high-level goals:
>
> 1) Smoothing out issues of code sharing between peers on a software project.
> 2) Smoothing out issues of transitioning code into Acceptance Testing
>
> Open source projects tend to blur the lines between these two groups
> (your users are your peers, after a fashion), but where CI tools
> really shine is in bringing some much-needed sanity to enterprise and
> commercial software development.  In these environments, tagging of
> each 'good' build is not just a neat idea, it's frequently necessary
> in order to have frank and honest conversations about what behaviors
> are to be expected in which versions of the code.
>
> Some people simply make tagging, versioning and promoting part of
> their process (especially if they happen to have someone as a
> Configuration Manager), but I've found it to be far simpler to have
> the tools automate these particular steps as much as possible, if for
> no other reason than it's another source for human error where no
> human intervention is really needed.  (Was that supposed to be build
> 246, or 247?)
>
> Could we perhaps have issue #51 reopened?
>
> Thanks,
> Jason Marshall
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

jason marshall-2
Good questions.

In the context of CI, I've worked on a few projects where multiple
teams were sharing my code (on the current one, I can no longer count
my 'customers' on one hand).  In these cases, simply introducing CI
achieved a sort of controlled chaos, and we put policies in place from
there to gain some sanity with code updates.  One of those policies is
putting major.minor.build version numbers in each JAR file, and
putting a matching tag in Subversion.  (I'm investigating Hudson as a
replacement for another tool, which has a lot of features we'll never
use, and a poorer overall user experience than Hudson).


If a piece of code is shared by more than a couple projects, then
development becomes driven by somebody else's delivery schedule.  On
any given day, odds are even that the code could be classified as
anything from ''feature complete' to 'code complete', because there
are only narrow windows during which major code overhauls can be
introduced.

In this case, 'promoting' the code most likely represents rolling a
couple bug fixes or minor feature into the code for whichever team is
currently blocked.  That means that tagging the code is the rule not
the exception, and in this case having a quick and easy way to tag
and/or promote builds becomes a necessity.

On projects that use my code, 'promote' usually means sending the code
off to QA.  Even here, once the code transitions out of development,
through QA, and closer to shipping, (Code complete, Feature complete,
maintenance), tagging the code eventually becomes the common case.

Since we, like a lot of Agile projects, ship on short cycles, that
means these tag-heavy cycles come around a few times a year.  And
what's a CI tool if not part of an Agile development toolkit?

Thanks,
Jason

On 11/30/06, Vladimir Sizikov <[hidden email]> wrote:

> Hi Jason,
>
> There was a discussion about builds "promotions" recently, and I filed
> a FEATURE #141 for this problem, and currently (in my spare time)
> trying to come up with Hudson plugin that provides this functionality.
>
> https://hudson.dev.java.net/issues/show_bug.cgi?id=141
>
> So I wonder, what do _you_ mean by "promotion" and could you please
> provide a use case for the feature, how do you see it should work?
>
> As for the second topic you've mentioned, tagging, I'm kind of with
> Kohsuke on this one, and currently don't see a good benefit of tagging
> every build. I guess, I miss some of the subtleties of your
> environment and your process, so if you could describe it in more
> detail, that would be great.
>
> Thanks,
>   --Vladimir
>
> --
> Vladimir Sizikov
> Sun Microsystems                   [hidden email]
>
>
> On Wed, Nov 29, 2006 at 01:17:16PM -0800, jason marshall wrote:
> > I found some references in the various documentation and reviews of
> > Hudson that implied that there was a way to 1) tag builds in the
> > source repository, and 2) 'promote' builds.
> >
> > Unfortunately I can't find any evidence of either in the Hudson UI.
> > Are these features that are no longer or not yet in the 1.64 build?
> > Both of these are of high interest to me, and I think also to the team
> > I work on.
> >
> >
> >
> >
> > I did find one bug report filed about tagging builds:
> >
> > https://hudson.dev.java.net/issues/show_bug.cgi?id=51
> >
> > This was closed as wontfix, with a challenge issued to the bug
> > originator to look deep in his heart and ask if that's what he really
> > wanted.
> >
> >
> > Well, I'm here to say that that's what I really wanted.
> >
> >
> > Continuous Integration tools should have two high-level goals:
> >
> > 1) Smoothing out issues of code sharing between peers on a software project.
> > 2) Smoothing out issues of transitioning code into Acceptance Testing
> >
> > Open source projects tend to blur the lines between these two groups
> > (your users are your peers, after a fashion), but where CI tools
> > really shine is in bringing some much-needed sanity to enterprise and
> > commercial software development.  In these environments, tagging of
> > each 'good' build is not just a neat idea, it's frequently necessary
> > in order to have frank and honest conversations about what behaviors
> > are to be expected in which versions of the code.
> >
> > Some people simply make tagging, versioning and promoting part of
> > their process (especially if they happen to have someone as a
> > Configuration Manager), but I've found it to be far simpler to have
> > the tools automate these particular steps as much as possible, if for
> > no other reason than it's another source for human error where no
> > human intervention is really needed.  (Was that supposed to be build
> > 246, or 247?)
> >
> > Could we perhaps have issue #51 reopened?
> >
> > Thanks,
> > Jason Marshall
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
- Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Jesse Glick
jason marshall wrote:
> One of those policies is putting major.minor.build version numbers in
> each JAR file, and putting a matching tag in Subversion.

Why not skip the Subversion tags and just put the svn rev # as the build
number in the JAR? More precise, works with any CI tool, and you should
be able to map them back to a build # if you needed to. But I think the
svn rev # would in fact be more useful than a build # for diagnosis, not
less - you can e.g. diff a source file from the mentioned rev # to head
to see if a bug has been fixed since that build was made. If you're
deliberately promoting a specific build (e.g. a weekly "known good"
build) then adding a svn tag is a good idea.

If you're using CVS, tagging each build quickly becomes impractical with
a large source base (as we have found on netbeans.org), due to CVS'
nonscalable handling of tags. Better to use a simple date.

-J.

--
[hidden email]  x22801  netbeans.org  ant.apache.org
       http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

jason marshall-2
On 12/1/06, Jesse Glick <[hidden email]> wrote:
> jason marshall wrote:
> > One of those policies is putting major.minor.build version numbers in
> > each JAR file, and putting a matching tag in Subversion.
>
> Why not skip the Subversion tags and just put the svn rev # as the build
> number in the JAR?

I do that as well.

> More precise, works with any CI tool, and you should
> be able to map them back to a build # if you needed to.

Repeatability.  One of the reasons CI tools do clean checkouts every
build is so that I know when my coworker gets back from vacation, or
joins the project, that s/he can get the same build I have.  This
provides a lot of repeatability, but if you stop there, you're
short-changing yourself.  With a tagged build, I can get forensic
information out of your repository.   There's an audit trail of which
code changes correspond to which builds, maintained with the precision
only a computer can manage.  I can figure out which bugs people
-thought- they fixed in which versions, and then figure out which
versions actually managed to fix the bugs.

Additionally, with sufficient documentation of my tool chain (which
versions go with which builds), I have better odds of precisely
recreating a build after the fact than I do of being able to locate
the original files.

Most times you're lucky if you can get a diligent backup of your code
repository, let alone anything else.  If you are fortunate to have a
backup schedule for other project artifacts, I can virtually guarantee
you that it will have lower fidelity than your repository backup.  If
nothing else, build artifacts tend to grow faster than the source that
generates them.  Sooner or later you'll 'fill up' the backup server,
and either you'll 1) do backups less frequently 2) stop doing backups
entirely, 3) pay through the nose for a bigger backup system,  or 4)
start throwing out artifacts that you don't think you'll need anymore.


> But I think the
> svn rev # would in fact be more useful than a build # for diagnosis, not
> less - you can e.g. diff a source file from the mentioned rev # to head
> to see if a bug has been fixed since that build was made. If you're
> deliberately promoting a specific build (e.g. a weekly "known good"
> build) then adding a svn tag is a good idea.

In Subversion, a tag and a rev number are virtually synonymous.  Any
SVN browser can tell you precisely which changelist a tag was created
from.

> If you're using CVS, tagging each build quickly becomes impractical with
> a large source base (as we have found on netbeans.org), due to CVS'
> nonscalable handling of tags. Better to use a simple date.

Every CI tool that I've seen that supports build tagging makes it so
that it can be turned off (and I turn it off myself from time to
time).  If memory serves, some even disable it by default.

Know thy customer.  People using CI tools are using a number of other
tools (like JUnit) because they are complementary.  CVS and CI are NOT
complementary tools, for some of the very same reasons you cite above.
 If I heard of someone who was thinking about using CI, but not
thinking about Subversion or Perforce, I'd strongly encourage them to
start working on both (hint hint).  If you're using Continuous
Integration, odds are very good that you're also using Refactoring. If
you haven't felt the pain of trying to track source of a bug
introduction across a file rename in CVS, it's only because you didn't
know what to blame for your suffering.

I support CI tools having CVS compatibility, but as a means to an end.
 I don't think a CI tool should support CVS because doing so is a good
idea, I think it should support it because requiring someone to
convince management to support a repository migration -before-
(instead of concurrent with) convincing them to support a CI tool is a
bad idea.



If you're still not convinced, is this something that would be
possible through the plugin API?  If so, where should I start?

Thanks,
Jason Marshall


> -J.
>
> --
> [hidden email]  x22801  netbeans.org  ant.apache.org
>        http://google.com/search?q=e%5E%28pi*i%29%2B1
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
- Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Jesse Glick
jason marshall wrote:
> is this something that would be possible through the plugin API?

Possibly (Kohsuke would know for sure). You can check in the sources;
every object a plugin can register is marked with a special interface.

-J.

--
[hidden email]  x22801  netbeans.org  ant.apache.org
       http://google.com/search?q=e%5E%28pi*i%29%2B1

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Kohsuke Kawaguchi-2
In reply to this post by jason marshall-2
jason marshall wrote:
> I found some references in the various documentation and reviews of
> Hudson that implied that there was a way to 1) tag builds in the
> source repository, and 2) 'promote' builds.

(1) is doable today. You can go to any of the builds and click "tag this
build" to set a tag on a new build. This is a manual process, so it's
not suitable if you want every build to be tagged. To tag a build
automatically for every build, I think you can write a plugin and
implement a "Publisher" that does that.

If you are interested in doing that, that would be great, and we can
help you. It would be a great addition, as clearly some people want it.


(2) is being discussed. The current idea is to plug in a custom project
type that serves as a view of another job (which is a CI build), then
occasionally (and maybe manually or by some automated means) a CI build
is "promoted".

This needs a bit more thinking, as none of us are quite sure that the
notion of "promotion" is the same across the board, and this extension
point of Hudson is not exercised enough (so we might have to change
Hudson to accomodate the needs.) So your use case would be greatly
appreciated.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

jason marshall-2
Perhaps I'm not looking in the right place.  Where on the UI is the
'tag this build' link?

Thanks,
Jason Marshall

On 12/6/06, Kohsuke Kawaguchi <[hidden email]> wrote:

> jason marshall wrote:
> > I found some references in the various documentation and reviews of
> > Hudson that implied that there was a way to 1) tag builds in the
> > source repository, and 2) 'promote' builds.
>
> (1) is doable today. You can go to any of the builds and click "tag this
> build" to set a tag on a new build. This is a manual process, so it's
> not suitable if you want every build to be tagged. To tag a build
> automatically for every build, I think you can write a plugin and
> implement a "Publisher" that does that.
>
> If you are interested in doing that, that would be great, and we can
> help you. It would be a great addition, as clearly some people want it.
>
>
> (2) is being discussed. The current idea is to plug in a custom project
> type that serves as a view of another job (which is a CI build), then
> occasionally (and maybe manually or by some automated means) a CI build
> is "promoted".
>
> This needs a bit more thinking, as none of us are quite sure that the
> notion of "promotion" is the same across the board, and this extension
> point of Hudson is not exercised enough (so we might have to change
> Hudson to accomodate the needs.) So your use case would be greatly
> appreciated.
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   [hidden email]
>
>
>


--
- Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Kohsuke Kawaguchi-2
In reply to this post by jason marshall-2
jason marshall wrote:

>> More precise, works with any CI tool, and you should
>> be able to map them back to a build # if you needed to.
>
> Repeatability.  One of the reasons CI tools do clean checkouts every
> build is so that I know when my coworker gets back from vacation, or
> joins the project, that s/he can get the same build I have.  This
> provides a lot of repeatability, but if you stop there, you're
> short-changing yourself.  With a tagged build, I can get forensic
> information out of your repository.   There's an audit trail of which
> code changes correspond to which builds, maintained with the precision
> only a computer can manage.  I can figure out which bugs people
> -thought- they fixed in which versions, and then figure out which
> versions actually managed to fix the bugs.
>
> Additionally, with sufficient documentation of my tool chain (which
> versions go with which builds), I have better odds of precisely
> recreating a build after the fact than I do of being able to locate
> the original files.
Have you looked at the fingerprinting support in Hudson? I use that
quite often for exactly what you are describing here. With fingerprints,
Hudson and I can track which jar file belongs to which build, so when
something goes wrong, we can easily correlate the problem with the build
numbers.


I never needed to re-run the build by using the tag, so I never
understood why it's useful (also, jar file contains timestamps, so even
if you use the same tag you are guaranteed to get a different jar file.)
This is not to say that there's no point in repeating a build, but I'm
just wondering if fingerprinting feature would provide a good enough
solution for you, instead of writing a plugin, which is a bit more
involved work.


> Most times you're lucky if you can get a diligent backup of your code
> repository, let alone anything else.  If you are fortunate to have a
> backup schedule for other project artifacts, I can virtually guarantee
> you that it will have lower fidelity than your repository backup.  If
> nothing else, build artifacts tend to grow faster than the source that
> generates them.  Sooner or later you'll 'fill up' the backup server,
> and either you'll 1) do backups less frequently 2) stop doing backups
> entirely, 3) pay through the nose for a bigger backup system,  or 4)
> start throwing out artifacts that you don't think you'll need anymore.

One feature of fingerprinting is that if builds in downstream projects
(projects that use your stuff) are using certain builds of your project,
Hudson can automatically keep your build artifacts. Perhaps it might
help a bit here.


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Renaud Bruyeron-2
In reply to this post by jason marshall-2
jason marshall wrote:
> Perhaps I'm not looking in the right place.  Where on the UI is the
> 'tag this build' link?

I don't think I saw the beginning of the thread, but are you using SVN ?
I am, and I do not see the "tag this build" link either on my projects...

 - Renaud

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Vladimir Sizikov
Hi,

On Thu, Dec 07, 2006 at 08:56:06AM +0100, Renaud Bruyeron wrote:
> jason marshall wrote:
> >Perhaps I'm not looking in the right place.  Where on the UI is the
> >'tag this build' link?
>
> I don't think I saw the beginning of the thread, but are you using SVN ?
> I am, and I do not see the "tag this build" link either on my projects...

My understanding was that "Tag this build" is only working with CVS
projects, at least that's what I see, all CVS projects do have the
button and all Subversion projects don't have it.

But for Subversion, this is not as critical as for CVS, since knowing
the revision number essentially gives a user a full snapshot of
repository stat at the particular moment (when the build started), so
it's rather easy to figure out which repository state corresponds to
particular build in Hudson.

Thanks,
  --Vladimir

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Kohsuke Kawaguchi-2
In reply to this post by Renaud Bruyeron-2
Renaud Bruyeron wrote:
> jason marshall wrote:
>> Perhaps I'm not looking in the right place.  Where on the UI is the
>> 'tag this build' link?
>
> I don't think I saw the beginning of the thread, but are you using SVN ?
> I am, and I do not see the "tag this build" link either on my projects...

Yes. It's only for CVS right now. Maybe we should do it with SVN, too.
"Tag this build" would find

   .*/trunk/.*

and then copy that to

   .*/tags/TAG/.*


--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: On tagging, lifecycle management

Kohsuke Kawaguchi-2
In reply to this post by jason marshall-2
jason marshall wrote:
> Perhaps I'm not looking in the right place.  Where on the UI is the
> 'tag this build' link?

See the attached screenshot. This is a build page of a CVS-based project.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

tagThilsBuild.png (52K) Download Attachment
smime.p7s (4K) Download Attachment