Changes since the last deployment

Configuration of the post-deployment script

The changes in the project carried out since the time of the deployment are to be shown in the first example. The following example involves a project in which the reports on the FirstSpirit content store can be managed. An overview of the changes to the data records is to be made available each time a project is deployed. A post-deployment script is first created in the deployment schedules to determine the changes.

The script first determines the ID of the revision which was current at the time of the last deployment of the project:

task = context.getTask();
lastExecutionRevisionId = (Long) context.getVariable(task.getName() + ".revision");
if (lastExecutionRevisionId != null) {
	context.logInfo("revision of last execution=" + lastExecutionRevisionId);
	revId = lastExecutionRevisionId.longValue();}

Subsequently, all revisions of the project since the last deployment are retrieved. The revision with the just-determined revision ID is retrieved as the lower revision limit (“startRev”). The current revision at the time of deployment is determined as the upper revision limit:

startRev = project.getRevision(revId);
endRev = project.getRevision(context.getStartTime());
context.logInfo("startRev=" + startRev.id + ", endRev=" + endRev.id);
if (startRev.id == endRev.id) {
	context.logInfo("no changes detected");
} 
revisions = project.getRevisions(startRev, endRev, 0, null);

All of the determined revisions are then examined for changes in a loop:

checkChanges(revisions) {
	for (revision : revisions) {
		metaData = revision.getMetaData();
		operation = metaData.getOperation();
		if (operation != null) {
			type = operation.getType();
			switch (type) {
			case RevisionOperation.OperationType.CONTENT_COMMIT:
				..
				..
				break;
			}
		}
	}		

In the process, only changes to database content – in other words, of operation type CONTENT_COMMIT – are to be taken into account, and only the newly created and changed data records of a specific database table.

All newly generated and released data records are first determined via:

createdEntities = operation.getCreatedEntities();
releasedEntities = operation.getReleasedEntities();

This selection is then restricted to a specific database table (here: MyEntityTypName):

ENTITY_TYPE = "MyEntityTypName";
if (ENTITY_TYPE.equals(created.getEntityTypeName())){
..
}
if (ENTITY_TYPE.equals(released.getEntityTypeName())) {
..
}

Related:

case RevisionOperation.OperationType.CONTENT_COMMIT:
	createdEntities = operation.getCreatedEntities();
	for (created : createdEntities) {
		if (ENTITY_TYPE.equals(created.getEntityTypeName())) {
		createdCertificates.put(created.getEntityId(), revision);
		context.logInfo("\t created entity " + created.getEntityId() + " in revision " + getRevisionString(revision));
		}
	}
	releasedEntities = operation.getReleasedEntities();
	for (released : releasedEntities) {
		if (ENTITY_TYPE.equals(released.getEntityTypeName())) {
		releasedCertificates.put(released.getEntityId(), revision);
		context.logInfo("\t released entity " + released.getEntityId() + " in revision " + getRevisionString(revision));
		}
	}
	break;

The required information (e.g. review numbers) is retrieved using the IDs of the data records determined to be changed and released (“created” and “released”) and then saved for further use.

context.setProperty("created", createdList);
context.setProperty("updated", updatedList);

In the process, the values saved via context.setProperty(..) are only persistent within the current schedule; this means they can continue to be used in a subsequent action in the schedule with context.getProperty(..). In this example, the contents continue to be used in the following “Mail” action in the e-mail template:

Hallo,
$CMS_SET(created, #context.getProperty("created"))$$CMS_SET(updated, #context.getProperty("updated"))$
es wurden neue$CMS_IF(created != null)$($CMS_VALUE(created.size)$)$CMS_END_IF$ 
und geänderte$CMS_IF(updated != null)$($CMS_VALUE(updated.size)$)$CMS_END_IF$ 
Gutachten auf http://www.gutachten-online.de veröffentlicht.
$CMS_IF(created.size > 0)$Neue Gutachten:
=====================
$CMS_FOR(entity, created)$ * $CMS_VALUE(entity.Gutachtennr)$ ($CMS_VALUE(entity.Datum.format("dd.MM.yy"))$) - 
$CMS_VALUE(entity.Kennzeichen)$
$CMS_END_FOR$$CMS_END_IF$

$CMS_IF(updated.size > 0)$Aktualisierte Gutachten:
=====================
$CMS_FOR(entity, updated)$ * $CMS_VALUE(entity.Gutachtennr)$ ($CMS_VALUE(entity.Datum.format("dd.MM.yy"))$) - 
$CMS_VALUE(entity.Kennzeichen)$
$CMS_END_FOR$$CMS_END_IF$
--
Dies ist eine automatisch generierte E-Mail, die nach der Veröffentlichung neuer Gutachten verschickt wird.
Bei Fragen wenden Sie sich bitte an info@gutachten-online.de

The template now generates an e-mail when carrying out a deployment schedule with the generated and modified contents:

Example (e-mail):

Hallo,

es wurden neue(4) und geänderte(2) Gutachten auf 
http://www.gutachten-online.de
veröffentlicht.

Neue Gutachten:
=====================
 * AZ33048/D (10.08.10) - DO-WZ 1234
 * AZ45134/D (10.08.10) - DO-XY 4321
 * AZ46200/D (11.08.10) - EN-AA 1111
 * AZ50261/D (13.08.10) - BO-YZ 5566

Aktualisierte Gutachten:
=====================
 * AZ44356/D (10.08.10) - DO-ZZ 3388
 * AZ47709/D (05.05.08) - D-YY 9999
--
Dies ist eine automatisch generierte E-Mail, die nach der Veröffentlichung neuer Gutachten verschickt wird.
Bei Fragen wenden Sie sich bitte an info@gutachten-online.de

Content saved via context.setVariable(..) also continues to be persistent while running the current schedule (in contrast to saving content via context.setProperty(..)). This option is used in the example in order to save the revision at the time of the current schedule:

context.setVariable(task.getName() + ".revision", new Long(endRev.getId())); 

When starting the next schedule, this information can then be used to retrieve the revision ID which was current at the time of the last deployment of the project:

lastExecutionRevisionId = (Long) context.getVariable(task.getName() + ".revision");