Managing Releases with ControlTier

[AndreasEK]

Hi,

is there a way in ControlTier to lock packages against further
modification? I found a possibility in the WebUI but that does not
seem to affect the behaviour of the ProjectBuilder. The requirement is
that once a package is released, tested and scheduled for deployment
to production, it should not be possible to replace a package with a
new one.

Also ... our client finds it somewhat tidieous to assign a multitude
of of new package versions to different services. I have the feeling
that we missed something :( If you have 5 services, each with 4-5
packages, and some of the packages might be of a newer version, it is
kind of error prone to configure integration and production stages the
same as the test stage. => Is there a way to bundle packages as a
release? I found a release and releasetag attribute for a package
(http://doc36.controltier.org/wiki/Setting_up_a_Package_for_import)
but could not find any documentation about how these attributes should
be used.

Thanks for a few comments,
Andreas Ebbert-Karroum

[Anthony Shortland]

Hi Andreas,

By "replace a package" do you mean replace the package file in the (JackRabbit) repository, or replace the package resource in the Workbench project (resource model)?

How are you assigning packages to services now? Via Workbench? Project XML/load-resources? Package Change-Dependencies?

Anthony.

> --
> You received this message because you are subscribed to the Google Groups "ControlTier" group.
> To post to this group, send email to contr...@googlegroups.com
> To unsubscribe from this group, send email to controltier...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/controltier?hl=en
> http://wiki.controltier.org

[Andreas Ebbert-Karroum]

Hi Anthony

we use the maven plugin to execute the project builder import the new files to controltier:

<plugin>

  <groupId>com.controltier.ctl.maven.mojo</groupId>

  <artifactId>maven-ctl-plugin</artifactId>

  <version>1.1</version>

  <executions>

    <execution>

      <id>upload to controltier</id>

      <phase>pre-integration-test</phase>

      <goals>

        <goal>command</goal>

      </goals>

      <configuration>

        <ctlBase>${ctlBase}</ctlBase>

        <depot>${ctlProject}</depot>

        <type>Builder</type>

        <name>uit-builder-foo</name>

        <command>repoImport</command>

        <args>-extension tar.gz -filebase ${ctier.filebase}

          -targetdir ${project.build.directory} -type

          ${ctier.package-type}

          -buildstamp

          ${project.version}-${ctier.package-type}

          -packageBuildtimePattern "yyyy-MM-dd HH:mm:ss"</args>

      </configuration>

    </execution>

  </executions>

</plugin>

As you see, this includes the maven POM-version into the buildstamp.

Now maven convention is that there are SNAPSHOT and RELEASE versions. While for snapshots you could have many of them (you typically are only interested in the latest), for RELEASE versions, there can only be one. (Or rather there should be only one).

So when the maven build is for a SNAPSHOT-version, we would like the package to be replaced in ControlTier, but when we are dealing with a RELEASE-version, when there is already a package with that buildstampt, the repoImport should fail. 

To your other question, we moved from the workbench to load-resources (which is a big improvement, already). Looking into Change-Dependencies again. To rephrase what the wiki is trying to tell me: For all Services that belong to a Site, I can switch all packages to a newer version, by specifying the appropriate buildstamp. 

=> What happes with dependencies to packages that don't have such a buildstamp? Are they ignored?

=> New dependencies still have to be introduced with load-resources, I guess. 

=> Does the site/service, for which I change the dependencies be associated to the node from which I run the command?

Any idea, how I sync Change-Dependencies with the xmls & load-resources? At the moment, the XML files are in mercurial, and a push triggers a jenkins-job, which loads these new resources into ControlTier. If the model is then changed via Change-Dependencies, my XML files are out of sync, and I don't see an easy way to get them back in sync again.

Thanks for your help,

Andreas

2012/2/6 Anthony Shortland <ant...@controltier.com>

[Anthony Shortland]

Chuck will have an opinion on this too, but my first suggestion is don't use repoImport or the standard Jackrabbit DAV for artifact management ... use a standard Maven repository (like Nexus or Artifactory) and exploit the ControlTier Maven plug-in just to register package resources with your project whose pkgRepoUri attributes link to the Maven repository ... done this many times!

[Andreas Ebbert-Karroum]

Hi,

yes I read about that, but couldn't find a good documentation about how this is supposed to work. I agree that this sounds like a good solution to the problem (given that Nexus or Artifactory are configured so to not allow redeployment of already available release-artifacts :)

Andreas

2012/2/21 Anthony Shortland <ant...@controltier.com>