Simple release management with Configuration Manager

write a pre-trigger that "catches" the checkpoint event.

Inside the trigger you can do any checks you like (depending on your programming skills).

Another option would be to set up a build environment (e.g. using Maven, Jenkins) that automates the necessary operations "outside PTC" and only publishes it final results, depening on the rules you describe.

Hi Klaus Thierer‌,

I'm curious to understand why you'd actually have the built binary be part of the release object, because I would have expected the binary to be built on demand from the snapshot of the source files for that release.

As Matthias Rump‌ mentioned, you can create a pre-trigger that does any of these checks for you.  I'd expect the Source artifacts would be captured in Source Integrity, as would the executable, if that's what you care about.  Depending on how you generate the Documentation, it could either be contained in Integrity as a document type, or as Source artifacts (XML source files, PDFs, or whatever file formats you want for this). 

If you want to do this just with Source Integrity, you'd have to have some mechanism to capture the tests (Excel, CSVs, all the way up to something like the output of automated unit tests or a Jenkins driven test harness that are run when you attempt to do the Project release). 

So to meet your criteria of:

- Executable should be newer than all sources

- Test Report should be newer than Documentation and Executable

- Checkpointing with the state "Release" should only be allowed if above 2 conditions are met.

Restated:

Test Reports are newer than Documentation and Executable which are newer than Source

I would look at Generating the Source and Documentation at the time release is attempted.  If it all compiles/generates properly, I would then have tests run against both to ensure they are correctly generated against a unit testing framework/automated regression testing framework/etc (for the documentation, your tests might be as simple as checking to make sure the check-in date was later/newer than all source check-ins, if that's an implicit condition).  Generate the test reports from the test results.  If the results are correct, approve the release, or put it in a "pending manual confirmation of release" state or something similar.

If you were willing to get away from a Source Integrity/Configuration Management only approach, you should be able to capture all of the tests via the Test Management interface.  The project itself would probably be an Integrity Project Item on the Integrity Manager side.

Regards,
Kael