It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×1,305

question asked: Oct 31 '11, 2:43 a.m.
question was seen: 8,470 times
last updated: Oct 31 '11, 2:43 a.m.

Related questions

FAQ - How this Forum works

Usage of the version value

0
Chris Graham (367●8●14) | asked Oct 31 '11, 2:43 a.m.
Hi All.

I'm working for a company that has adopted RAM (7.5.0.2) as that asset repository. All of our deployable artefacts are to be stored there.

It has some schemas set up for it, to track approvals, deployments etc.

We've automated our builds to automatically upload the deployment artefacts into ram, add int he release notes etc.

All of that is fine.

The issue that I have with it all, it the version no.

The primary asset that I am concerned with is, eg:

WarpRelease.zip

It is versions, via our Maven builds as:

WarpRelease-1.0.0.1.zip
WarpRelease-1.0.0.2.zip

and so on.

Using a Name of "WarpRelease", a version of "1.0.0.1", "1.0.0.2" etc.

RAM will only show the name of the asset in the "recently submitted" list and in other places. A mouse hover is the only real way to how the details of each individual asset.

This is a *MAJOR* problem when we have a few hundred releases.

How is this tool, RAM, *meant* to be used?

I know that there is the manual "Create a new Version" button. And it's corresponding Ant Task. But, under such circumstances, I cann't see how this tool is meant to work well/be useable.

Our in-house ram person (from SWG, actually) has recommended that we do *NOT* use the version field at all (just set it as "1.0" and leave them all at that), and append the version value to the name.

So, following that, we'd have:

Name = "WarpRelease-1.0.0.1", Version "1.0"
Name = "WarpRelease-1.0.0.2", Version "1.0".

So, I'm all kind of lost as to how this is meant to work!

How *IS* it meant to work/be used?

-Chris

10 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Gili Mendel (1.8k●5●6) | answered Oct 31 '11, 8:27 a.m.
JAZZ DEVELOPER
... move up to RAM 7.5.1 (https://jazz.net/blog/index.php/2011/10/28/rational-asset-manager-7-5-1-is-now-available/).

... the various previews will show the versions now.
0
permanent link
Chris Graham (367●8●14) | answered Nov 03 '11, 6:00 p.m.
Hi Gili.

Thanks for the reply and link.

But I'd still like some more discussion on how the usage of RAM is envisioned when we have a few hundred releases of an asset.

-Chris

... move up to RAM 7.5.1 (https://jazz.net/blog/index.php/2011/10/28/rational-asset-manager-7-5-1-is-now-available/).

... the various previews will show the versions now.
0
permanent link
Gili Mendel (1.8k●5●6) | answered Nov 04 '11, 8:14 a.m.
JAZZ DEVELOPER
Sure,


Regarding the builds, do you require all of them to be available to everyone all the time, or would you have some life cycle to deprecate (or even delete) older ones? Also, do the versions have any convention that imply linage or compatibility between components?

It will help if you can shed some light on how many "different" build components there are, what is the relationships between them, and how are these builds used (after they are placed in RAM).
0
permanent link
Chris Graham (367●8●14) | answered Nov 13 '11, 7:52 p.m.
Sure,


Regarding the builds, do you require all of them to be available to everyone all the time, or would you have some life cycle to deprecate (or even delete) older ones? Also, do the versions have any convention that imply linage or compatibility between components?

It will help if you can shed some light on how many "different" build components there are, what is the relationships between them, and how are these builds used (after they are placed in RAM).


Hi Gili.

In our usage scenario, at the moment, we are using RAM as a deployment repository. Everything that is to be released into a non-dev environment should be stored in there.

We're using maven as our build tool, and I've tried the RAM uploads into the release process. So we only ever upload into RAM an official release, one that can be traced back to a tag in SVN (actually, the name of the asset is the SVN tag name).

This will create quite a large number of assets over time. To be honest, I don't think that the issue of asset retention has been adaptately addressed. However, for the moment, we keep the releases we need too, and some of the earlier ones have been deleted.

RAM will be used to track the deployment of assets into environemnts. We only have a few asset types:
Release Asset - the file bundle, release notes etc.
Environment Asset - the name of an environment in which Release Assets get deployed into.
Deployment Request Asset - Effectively a glue record, joining the above two together and recording approvals etc.

Each release asset is a <Name>-<Version>. The versions go up by one, each time we perform a release.

-Chris
0
permanent link
Chris Graham (367●8●14) | answered Nov 13 '11, 8:24 p.m.
Hi Gili.

The RAM Ant tasks require ANT 1.7.x.

Given that 1.8.2 is the latest available, are there any plans to support it?

Just curious.

-Chris
0
permanent link
Gili Mendel (1.8k●5●6) | answered Nov 14 '11, 9:01 a.m.
JAZZ DEVELOPER


...one that can be traced back to a tag in SVN (actually, the name of the asset is the SVN tag name).



You do not necessarily need to force the published asset's name as the SVN tag name (unless that tag is meaningful / intuitive when listed on a search result set). You can create an attribute (say SVN Tag) that you can search on if you wish
attribute:('SVN Tag'='*tag*')


You can also annotate the artifacts themselves to hold the SVN Tag, as well as a (HTML) link to a search, or to a build job. 

<property name="ram.asset.artifacts" value="${basedir}/build/image/${asset.impl.name}.zip" />

<ram:modify server="ramServer">

	<ram:search name="${ram.asset.name}" version="${ram.asset.version}" />

	<ram:asset>				

		<ram:name>${ram.asset.name}</ram:name>

		<ram:version>${ram.asset.version}</ram:version>

		<ram:community>${ram.asset.community}</ram:community>

		<ram:assetType>${ram.asset.type}</ram:assetType>

		

		....

			

		<ram:artifactSet src="${ram.asset.artifacts}">

			<!-- Create artifact references to the artifacts in the .zip file above with the following properties. -->

			<ram:reference>

				<ram:description>

						SVN TAG = ${svn.tag}


						BUILD_URL = <a href='${build.url}' target='_blank' > Build Info<a>


						SOURCE_REPOSITORY_ADDRESS = <a href='${src.repository}' target='_blank' > Source Repository<a>
 	

						BUILD_RESULT_UUID = ${build.id}
 						      			 

						BUILD_DEFINITION_ID = ${build.def.id}
  

			   </ram:description>

				<!-- Set the reference kind to "build reference." -->

				<ram:kind>com.ibm.ram.reference.build</ram:kind>

				<ram:value>

				</ram:value>

			</ram:reference>

		</ram:artifactSet>

				

		.....

	</ram:asset>

</ram:modify>




This will create quite a large number of assets over time. To be honest, I don't think that the issue of asset retention has been adaptately addressed. However, for the moment, we keep the releases we need too, and some of the earlier ones have been deleted.


Asset's end of life is important ... you do not want to get to a point where you "... can not see the trees for the forest". You drive this with a life cycle, where you try to allow so many "builds" from a particular release to be deployed ... move these older builds to a state when you need permissions/exception to download them


RAM will be used to track the deployment of assets into environemnts. We only have a few asset types:
Release Asset - the file bundle, release notes etc.
Environment Asset - the name of an environment in which Release Assets get deployed into.
Deployment Request Asset - Effectively a glue record, joining the above two together and recording approvals etc.

Each release asset is a <Name>-<Version>. The versions go up by one, each time we perform a release.


How many builds per Release assets are viable/deployed? Are there different build types/portions per release (e.g., release foo, platforms x, y, z or is it release foo deliverable 1, deliverable 2 ....)

Also how do you link the Env. and Deployment request asset? is it part of the deployment process?


... Given that 1.8.2 is the latest available, are there any plans to support it?



See https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/44210
0
permanent link
Chris Graham (367●8●14) | answered Nov 14 '11, 10:41 p.m.


...one that can be traced back to a tag in SVN (actually, the name of the asset is the SVN tag name).



You do not necessarily need to force the published asset's name as the SVN tag name (unless that tag is meaningful / intuitive when listed on a search result set). You can create an attribute (say SVN Tag) that you can search on if you wish
attribute:('SVN Tag'='*tag*')


You can also annotate the artifacts themselves to hold the SVN Tag, as well as a (HTML) link to a search, or to a build job. 

<property>

<ram>

	<ram>

	<ram>				

		<ram>${ram.asset.name}</ram>

		<ram>${ram.asset.version}</ram>

		<ram>${ram.asset.community}</ram>

		<ram>${ram.asset.type}</ram>

		

		....

			

		<ram>

			<Create>

			<ram>

				<ram>

						SVN TAG = ${svn.tag}


						BUILD_URL = <a href='${build.url}' target='_blank' > Build Info<a>


						SOURCE_REPOSITORY_ADDRESS = <a href='${src.repository}' target='_blank' > Source Repository<a>
 	

						BUILD_RESULT_UUID = ${build.id}
 						      			 

						BUILD_DEFINITION_ID = ${build.def.id}
  

			   </ram>

				<Set>

				<ram>com.ibm.ram.reference.build</ram>

				<ram>

				</ram>

			</ram>

		</ram>

				

		.....

	</ram>

</ram>


I've never understood how that reference, and particularly the description bit works. Where is the text entered in there shown/seen?



This will create quite a large number of assets over time. To be honest, I don't think that the issue of asset retention has been adaptately addressed. However, for the moment, we keep the releases we need too, and some of the earlier ones have been deleted.


Asset's end of life is important ... you do not want to get to a point where you "... can not see the trees for the forest". You drive this with a life cycle, where you try to allow so many "builds" from a particular release to be deployed ... move these older builds to a state when you need permissions/exception to download them


RAM will be used to track the deployment of assets into environemnts. We only have a few asset types:
Release Asset - the file bundle, release notes etc.
Environment Asset - the name of an environment in which Release Assets get deployed into.
Deployment Request Asset - Effectively a glue record, joining the above two together and recording approvals etc.

Each release asset is a <Name>-<Version>. The versions go up by one, each time we perform a release.



How many builds per Release assets are viable/deployed? Are there different build types/portions per release (e.g., release foo, platforms x, y, z or is it release foo deliverable 1, deliverable 2 ....)

We are just using a bundle (.zip) of our 6 or 7 separate components, mostly to minimise the separate number of different Release Assets we have. That may change however, as with the Deployment Rquest and Environment records, it may get a little more complex. So, currently, it is more like Release foo, Version x.y.z, that consists of deliverable 1, 2, etc.

Also how do you link the Env. and Deployment request asset? is it part of the deployment process?

No, the other way around. A release asset it tied to a specific environment by a deployment request.
So, the DR is raised, for a specific Env for a sepcific Release.
Then the DR is approved by the appropriate people, then the deployment takes place.
The DR record itself, requires two related assets, one of each type of Release and Environment. This must be encoded in the rules behind the DR type, as we can not save it until we've met that requirement/rule.



... Given that 1.8.2 is the latest available, are there any plans to support it?



See https://jazz.net/jazz02/resource/itemName/com.ibm.team.workitem.WorkItem/44210

Oooops. Cool. Thanks.

-Chris
0
permanent link
Chris Graham (367●8●14) | answered Nov 14 '11, 11:22 p.m.
As an aside. 

[code]

            <Set>

            <ram>com.ibm.ram.reference.build</ram>

            <ram></ram>

[/code]



Where, if anywhere, are the values of <kind> documented, and what do they mean?

-Chris
0
permanent link
Chris Graham (367●8●14) | answered Nov 17 '11, 11:40 p.m.
Um, ignore that, I was blind.

-Chris

As an aside. 

[code]

            <Set>

            <ram>com.ibm.ram.reference.build</ram>

            <ram></ram>

[/code]



Where, if anywhere, are the values of <kind> documented, and what do they mean?

-Chris
0
permanent link
Chris Graham (367●8●14) | answered Nov 17 '11, 11:46 p.m.

How many builds per Release assets are viable/deployed? Are there different build types/portions per release (e.g., release foo, platforms x, y, z or is it release foo deliverable 1, deliverable 2 ....)


Let me use the last project as a better example, in this context.

It was a message broker project, one that build around 60 or so BAR files. It as a monilothic build that build everything every time, and in good scm practice, all were deployed at once. I even generated the deployment script for each release as part of the release.

That project got to well over 240 releases (and that was just for the one release! There were up to about 4 releases in concurrent development).

Yes, something did need to be done about retiring assets, but it was still a large number of concurrent assets to work with at once.

-Chris

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.