Continuous Integration mit Liferay 6.1

Lean back and deploy!

Nataliya Wierts


Im Folgenden sollen drei Bereiche thematisiert werden:

Continuous-Integration-Tools und ihre VoraussetzungenContinuous Integration auf einem Web Application Server für LiferayContinuous Integration mit Liferay

Continuous Integration mit Liferay werden wir als unabhängig vom Web Application Server betrachten, weil Continuous Integration Recipes, die hier für Liferay dargestellt werden, problemlos genauso unter Apache Tomcat, WebLogic, JBoss oder WebSphere angewendet werden können.

Liferay hat eine relativ spezifische Lösung für Deployment-Prozesse, indem es die .war-Dateien in einem deploy-Verzeichnis verwaltet. Das erklärt sich dadurch, dass Liferay diese .war-Datei bearbeitet, eventuell mit eigenen tld-Dateien anreichert und web.xml abändert. Die Standard-.war-Applikationen werden im Gegensatz dazu einfach so übernommen, wie sie verpackt sind. Sie werden nur ausgepackt und ausgeführt. Standardapplikationen werden auch nicht in spezifischen deploy-Verzeichnissen von Liferay abgelegt, sondern im Web-Application-Verzeichnis. Das ist zum Beispiel entweder das webapp in Tomcat oder das Domain-Verzeichnis unter WebLogic.

Dieser Artikel geht nicht auf das Thema Unit und Integration Testing ein. Natürlich ist ein ausreichendes automatisches Testing eine Grundvoraussetzung für CI und wird daher als selbstverständlich vorausgesetzt.

Continuous-Integration-Tools und ihre Voraussetzungen

Um Continuous Integration (CI) und Continuous Deployment (CD) zu ermöglichen, brauchen wir zuerst ein CI-/CD-Tool. Davon gibt es viele auf dem Markt: TeamCity, Hudson, Jenkins, Atlassian Bamboo und zahlreiche andere. Diese Tools bieten oftmals ähnliche Funktionalitäten und ermöglichen die Gestaltung von Deployment-Prozessen in mehreren Stufen. Als Ausführungswerkzeug, die Deployment-Stufen zu gestalten, gibt es Maven-, Ant-, oder sogar Bash-Skripte. Da wir uns im Java-Umfeld befinden und mit Apache Maven gesegnet sind, entscheiden wir uns dafür, Maven einzusetzen. Warum nicht Apache Ant? Die „Ameise“ ist zwar fleißig, Maven benötigt aber im Vergleich zu Apache Ant viel weniger Code, um Standardprozesse zu implementieren.

Wir erstellen mit unseren Portlets ein erstes Maven-­.war-Modul, das auch andere jar-Bibliotheken als Dependencies enthält. Wenn unsere Portlets in einem Maven-Modul verpackt sind, dann können wir in unserem CI-Tool Maven als Build-Prozess auswählen und als Erstes bei jedem Git- bzw. SVN-Commit-Trigger Maven-Tasks ausführen: mvn clean compile. So haben wir die erste einf...

Continuous Integration mit Liferay 6.1

Lean back and deploy!

Nataliya Wierts


Im Folgenden sollen drei Bereiche thematisiert werden:

Continuous-Integration-Tools und ihre VoraussetzungenContinuous Integration auf einem Web Application Server für LiferayContinuous Integration mit Liferay

Continuous Integration mit Liferay werden wir als unabhängig vom Web Application Server betrachten, weil Continuous Integration Recipes, die hier für Liferay dargestellt werden, problemlos genauso unter Apache Tomcat, WebLogic, JBoss oder WebSphere angewendet werden können.

Liferay hat eine relativ spezifische Lösung für Deployment-Prozesse, indem es die .war-Dateien in einem deploy-Verzeichnis verwaltet. Das erklärt sich dadurch, dass Liferay diese .war-Datei bearbeitet, eventuell mit eigenen tld-Dateien anreichert und web.xml abändert. Die Standard-.war-Applikationen werden im Gegensatz dazu einfach so übernommen, wie sie verpackt sind. Sie werden nur ausgepackt und ausgeführt. Standardapplikationen werden auch nicht in spezifischen deploy-Verzeichnissen von Liferay abgelegt, sondern im Web-Application-Verzeichnis. Das ist zum Beispiel entweder das webapp in Tomcat oder das Domain-Verzeichnis unter WebLogic.

Dieser Artikel geht nicht auf das Thema Unit und Integration Testing ein. Natürlich ist ein ausreichendes automatisches Testing eine Grundvoraussetzung für CI und wird daher als selbstverständlich vorausgesetzt.

Continuous-Integration-Tools und ihre Voraussetzungen

Um Continuous Integration (CI) und Continuous Deployment (CD) zu ermöglichen, brauchen wir zuerst ein CI-/CD-Tool. Davon gibt es viele auf dem Markt: TeamCity, Hudson, Jenkins, Atlassian Bamboo und zahlreiche andere. Diese Tools bieten oftmals ähnliche Funktionalitäten und ermöglichen die Gestaltung von Deployment-Prozessen in mehreren Stufen. Als Ausführungswerkzeug, die Deployment-Stufen zu gestalten, gibt es Maven-, Ant-, oder sogar Bash-Skripte. Da wir uns im Java-Umfeld befinden und mit Apache Maven gesegnet sind, entscheiden wir uns dafür, Maven einzusetzen. Warum nicht Apache Ant? Die „Ameise“ ist zwar fleißig, Maven benötigt aber im Vergleich zu Apache Ant viel weniger Code, um Standardprozesse zu implementieren.

Wir erstellen mit unseren Portlets ein erstes Maven-­.war-Modul, das auch andere jar-Bibliotheken als Dependencies enthält. Wenn unsere Portlets in einem Maven-Modul verpackt sind, dann können wir in unserem CI-Tool Maven als Build-Prozess auswählen und als Erstes bei jedem Git- bzw. SVN-Commit-Trigger Maven-Tasks ausführen: mvn clean compile. So haben wir die erste einf...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang