Progress OpenEdge ontwikkelstraat anno 2014 (deel 1)

broncoDit is het eerste artikel in een reeks over de OpenEdge ontwikkelomgeving. Aan bod komen allerlei zaken die productiviteit en kwaliteit kunnen verhogen. Ik zal het hebben over tooling voor de OpenEdge ontwikkelomgeving, daarbij bespreek ik een aantal open source producten die het leven eenvoudiger maken.

Integrated Development Environment
Progress heeft een aantal jaren geleden besloten zijn ontwikkelomgeving aan te laten sluiten bij de hedendaagse complexiteit van de IT omgevingen. Dit is onder andere gedaan door de introductie van een Integrated Development Environment (IDE) en OpenEdge Architect, inmiddels omgedoopt tot Progress Developer Studio. Deze IDE is een incarnatie van Eclipse. Eclipse is een op Java gebaseerd framework om ontwikkelomgevingen te bouwen. Het kenmerk van Eclipse is dat het werkt met een plugin model. Deze plugins kunnen via uitgekiende interfaces onderling communiceren. Dit laatste is van belang omdat op deze wijze allerlei zaken die niet door Progress Software worden geleverd toch kunnen worden opgenomen in de IDE en het met elkaar kan samenwerken. Voorbeelden hiervan zijn versiebeheer en taakbeheer. Het grote voordeel van de inzet van een IDE is dat het overzicht verschaft. Alle resources en informatie over deze resources in één scherm. Combineer dit met onder andere directe syntax check, code completion en de voordelen worden al snel duidelijk.

Versiebeheer
Een afgeleide van het gebruik van Eclipse is dat het ook mogelijk is om tooling te gebruiken die afkomstig is uit het Open Source domein. Voorbeelden hiervan voor versiebeheer zijn SVN, Mercurial en Git. Zowel de server software als de plugins voor Eclipse zijn kosteloos te krijgen en worden ondersteund door een flinke enthousiaste community. Het voordeel van Mercurial en Git is het distributed model. Concreet houdt dit in dat iedere ontwikkelaar zijn eigen (versiebeheer) repository heeft en deze op door hem/haar gewenste moment kan synchroniseren met de centrale repository. Dit maakt het eenvoudig om thuiswerken of remote teams te ondersteunen zonder dat deze continue online hoeven te zijn.

Builds maken
Welnu, de software is geschreven, alles staat netjes in het versiebeheersysteem. Er moet alleen nog een build van worden gemaakt. Ook hier voorziet de Open Source community in. Uit de Java wereld komt Ant en uit de OpenEdge community komt PCT. Ant maak het mogelijk om buildscripts (xml) te maken en PCT is een extension voor Ant die alle OpenEdge taken mogelijk maakt. Denk hierbij aan compileren, databasetabellen dumpen, pl-files maken en dergelijken. Deze combinatie maakt het mogelijk om het complete buildproces te scripten en te eindigen met een keurige zip file met daarin het complete product. De bovenstaande stack maak het mogelijk om te ontwikkelen, versies te beheren en de software te bouwen. Het laatste moet echter met de hand geïnitieerd worden en moet uiteraard worden gecombineerd worden met versiebeheer.

Continuous Integration
Jenkins is een zogenaamde Continuous Integration tool. In kort maakt deze tools het mogelijk om builds van de diverse versie te plannen en uit te voeren door het uitvoeren van Ant scripts. Uiteraard is het dan ook mogelijk om signalen (mails) uit te sturen indien het fout gaat. Daarnaast is het ook mogelijk om Jenkins zo te configureren dat bij iedere check-in van software in het versiebeheersysteem een volledige compile van de software wordt gemaakt om te controleren of de consistentie nog in orde is.

Uitbreiding ontwikkelstraat
Bovenstaande combinatie van producten (Eclipse, versiebeheer, Ant & Jenkins) is een combinatie die nog veel meer mogelijkheden biedt. Op termijn is het mogelijk om de ontwikkelstraat uit te breiden met Unit testing, task management, issue management en dit op elkaar te laten aansluiten. Al deze producten hebben een grote en enthousiaste community waardoor er altijd voldoende kennis voor handen is om plooitjes glad te strijken. Het voordeel van het gebruik is dat een groot deel van inspanning die nodig voor een gedegen ontwikkelstraat van de plank gepakt kan worden. De kosten van de ontwikkelstraat gaan omlaag, terwijl de kwaliteit en inzichtelijkheid omhoog gaan. In een volgend blogbericht ga ik verder in op de implementatie en mogelijkheden van deze producten.