You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2007/04/01 15:21:32 UTC
Deploying Staged Releases
Hi,
Yesterday I whipped off a staging repository copier and it focuses on
pulling from any source, but only deploys using scp. I did this
because it's the only method we have for reliably getting a release
to a server and being able to recover if something goes wrong.
Ideally this would be done on a single machine to be the most
reliable, and a custom protocol will most likely be needed as our
repository structure does make it a little tricky to pull off a
deployment in a completely atomic fashion, but this new tool comes
pretty close. It does the following:
1) Pulls the contents of the staging repository to the local machine.
2) Looks for any metadata in the staging repository and finds any
matches in the target repository and downloads the metadata from the
target repository and gives it a different name.
3) The metadata from the staging repository is merged with the
metadata from the target repository
4) All metadata and version directories are given a suffix like the
following:
maven-artifact
|-- 2.0.6.rip
| ... (all the artifacts/sources/javadocs)
|-- maven-metadata.xml.md5.rip
|-- maven-metadata.xml.rip
`-- maven-metadata.xml.sha1.rip
5) A shell script is generated which knows how to renamed the
suffixed resources to something Maven can utilized
6) The deployment is zipped up along with the renaming script
7) The zip file is moved to the root the target repository
8) The zip is unpacked, overwriting anything of the same name
9) The rename script is run to make the above look normal like:
maven-artifact
|-- 2.0.6
| ... (all the artifacts/sources/javadocs)
|-- maven-metadata.xml.md5
|-- maven-metadata.xml
`-- maven-metadata.xml.sha1
So up to 8) if anything goes wrong at worst you are left with some
crap ".rip" directories or crap .rip metadata files. Maven doesn't
know what these are and no user will be affected. We can write a
shell script to clean these directories up. The rename script was the
only thing I could come up with that was as close to atomic as we can
get. Ideally a whole release would be contained in a single directory
which would then make a release atomic because it's a single rename
operation which in most OSes (I can't think of any that aren't) this
is atomic. I tested this with Maven 2.0.6 itself and all the metadata
is updated correctly and the content is moved over properly.
I also take into account the recalculation of the checksums after the
merging of the metadata so those are updated as well and given the
suffix and moved into place by the rename script. The only thing I'm
not doing is the recalculation of the PGP signature. I ran out of
time as I wanted to do the release. I can live with that and will try
to incorporate some Java tool to do this.
That's the update. 2.0.6 is released, now I'll do the Ant Tasks and
try this tool again.
Jason.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Deploying Staged Releases
Posted by Jason van Zyl <ja...@maven.org>.
I will test this once more today with the Ant Tasks, then I'll write
it up and put the plugin up for a 1.0-alpha-1. It's really a stopgap
until we have a proper solution but will work for any of our releases
in the meantime.
Jason.
On 1 Apr 07, at 9:21 AM 1 Apr 07, Jason van Zyl wrote:
> Hi,
>
> Yesterday I whipped off a staging repository copier and it focuses
> on pulling from any source, but only deploys using scp. I did this
> because it's the only method we have for reliably getting a release
> to a server and being able to recover if something goes wrong.
> Ideally this would be done on a single machine to be the most
> reliable, and a custom protocol will most likely be needed as our
> repository structure does make it a little tricky to pull off a
> deployment in a completely atomic fashion, but this new tool comes
> pretty close. It does the following:
>
> 1) Pulls the contents of the staging repository to the local machine.
>
> 2) Looks for any metadata in the staging repository and finds any
> matches in the target repository and downloads the metadata from
> the target repository and gives it a different name.
>
> 3) The metadata from the staging repository is merged with the
> metadata from the target repository
>
> 4) All metadata and version directories are given a suffix like the
> following:
>
> maven-artifact
> |-- 2.0.6.rip
> | ... (all the artifacts/sources/javadocs)
> |-- maven-metadata.xml.md5.rip
> |-- maven-metadata.xml.rip
> `-- maven-metadata.xml.sha1.rip
>
> 5) A shell script is generated which knows how to renamed the
> suffixed resources to something Maven can utilized
>
> 6) The deployment is zipped up along with the renaming script
>
> 7) The zip file is moved to the root the target repository
>
> 8) The zip is unpacked, overwriting anything of the same name
>
> 9) The rename script is run to make the above look normal like:
>
> maven-artifact
> |-- 2.0.6
> | ... (all the artifacts/sources/javadocs)
> |-- maven-metadata.xml.md5
> |-- maven-metadata.xml
> `-- maven-metadata.xml.sha1
>
> So up to 8) if anything goes wrong at worst you are left with some
> crap ".rip" directories or crap .rip metadata files. Maven doesn't
> know what these are and no user will be affected. We can write a
> shell script to clean these directories up. The rename script was
> the only thing I could come up with that was as close to atomic as
> we can get. Ideally a whole release would be contained in a single
> directory which would then make a release atomic because it's a
> single rename operation which in most OSes (I can't think of any
> that aren't) this is atomic. I tested this with Maven 2.0.6 itself
> and all the metadata is updated correctly and the content is moved
> over properly.
>
> I also take into account the recalculation of the checksums after
> the merging of the metadata so those are updated as well and given
> the suffix and moved into place by the rename script. The only
> thing I'm not doing is the recalculation of the PGP signature. I
> ran out of time as I wanted to do the release. I can live with that
> and will try to incorporate some Java tool to do this.
>
> That's the update. 2.0.6 is released, now I'll do the Ant Tasks and
> try this tool again.
>
> Jason.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org