Progress OpenEdge
Vertel me meer over je applicatie en hoe we kunnen helpen met Progress OpenEdge werkzaamheden.
CI/CD in combinatie met Progress OpenEdge
Hoe start je daar mee?
We vroegen Harold (één van onze Progress OpenEdge-specialisten) wat hij klanten adviseert om te doen. Hoe start je? “Bij CI/CD i.c.m. Progress OpenEdge is het altijd verstandig om klein te beginnen. Je weet nog niet exact wat je er mee wilt, of misschien mee kunt. Groter kan altijd nog, maar juist als je klein start kun je gefaseerd werken en ontdekken wat voor jouw project of organisatie handig is. Dat betekent niet dat je niet groot mag denken. Absoluut, dat is juist prettig. Maar om de investering initieel laag te houden, is het voor ieder project waarin je CI/CD met Progress OpenEdge gaat combineren, altijd verstandig om klein te starten, ook als je groot wilt gaan.”
Zo werken we bij Flusso. Vanuit een laagdrempelige en gefaseerde aanpak, samen, eerlijk. Ook als je ons medium of large pakket wilt (zie onder), start dan altijd met het kleine (small) pakket. Waarom we niet meteen het grootste pakket adviseren? Omdat dat eerlijker is. Vanuit het kleine pakket kun je altijd nog opschalen naar een groter pakket. En in de ontwikkeling van software, waaronder bij CI/CD i.c.m. Progress OpenEdge, is het veelal verstandig om klein te starten, zodat je de scope van het project kunt aftasten. Heb je niet meteen met hogere kosten te maken, maar met behapbare kosten. Of je nu bij een klein, middelgroot of groot bedrijf werkt, klein starten is dus altijd verstandig.
Ben je nu of binnenkort nieuwsgierig naar de kracht van CI/CD i.c.m. Progress OpenEdge en vind je het fijn dat we een quickscan doen om te beoordelen of het voor jouw project interessant is om CI/CD in te zetten? Vraag dan onze gratis quickscan aan. Ook deze scan is geheel vrijblijvend.
Het blijft natuurlijk maatwerk en een echte standaard bij CI/CD i.c.m. Progress OpenEdge is er niet. Maar grofweg zijn er 3 opties, al behoort een combinatie ook tot de mogelijkheden. Zoals we hierboven al zeiden, adviseren we je vaak om te starten met het kleinste pakket (S), opschalen kan altijd nog. Welke stappen er horen bij welk optie? Die hebben we voor je op een rij gezet:
Stap 1: jouw code komt in een versie-controlesysteem te staan, denk aan roundtable, subversion en git.
Stap 2: daarna gebruiken we Progress Compilation Tools (PCT), Apache Ant en een build.xml die op basis van enkele initiële variabelen de volgende taken uitvoert: createdb, compile en package
Stap 3: hieruit volgt een build artifact (meestal een .zip) die vervolgens wordt gedeployed op een omgeving. Deze deploy is een zogeheten eenvoudige deploy. Wat wil zeggen dat de .pl files op hun plek worden gezet. Hierbij worden wél structuurwijzigingen op de databaseschema’s meegenomen, maar geen dataconversies. Dit heet ook wel een stateless deploy.
P.s. dit geautomatiseerde proces draait op een speciaal ingerichte machine waardoor er repeatable builds worden gedaan die niet afhankelijk zijn van een ontwikkelaar, bijvoorbeeld op basis van Jenkins.
Alles vanuit optie S, maar dan uitgebreid met dataconversies, tests en simpele code quality checks.
Stap 1 – Dataconversies: bij het deployen van de applicatie komt veelal ook het migreren van data aan de orde. Hiervoor is (soms) een dump/restore nodig van de draaiende database(s) en het kost enige tijd om dit goed te automatiseren.
Stap 2 – Tests: tijd om te testen. Naast unit tests kunnen we hier ook api-tests uitvoeren. Door de hoeveelheid tests, kan het zijn dat het op termijn niet meer haalbaar is om na elke commit alle tests uit te voeren. Strategieën om dit te verbeteren vallen onder optie L.
Stap 3 – Code Quality: het is mogelijk om de code te laten controleren op fouten en stijl, bijvoorbeeld door SonarQube. Dit serieus aanpakken? Dan is het nodig om hiervoor licenties te kopen, onderdeel van optie L.
Alles vanuit optie S en M, maar dan optimaliseren en breiden we de build uit. Zodat deze aan de eisen voldoet van grotere projecten.
Stap 1: parallelliseren van build-stappen om de totale bouwtijd te verkorten en het mogelijk te maken om ook bij grotere projecten alle relevante code bij elke commit door te laten testen.
Stap 2: serieuze controle van de code op fouten en style. Hiervoor is het nodig om SonarQube licenties aan te schaffen, zodat deze standaard meegenomen worden bij elke build.
Stap 3: rapportages van de verschillende testen en integraties met workflow-tools, zoals JIRA.
Voorkomen dat je project meer geld kost dan nodig? Plan een gratis sparsessie in. Gratis en vrijblijvend.
Je bent misschien op een punt gekomen dat je overtuigd bent geraakt van de kracht van CI/CD i.c.m. Progress OpenEdge. Nu rest de vraag nog: ‘Hoe ga ik mijn project aanpakken?’ Ga je alles zelf doen of besteed je (een gedeelte) uit?
Wil je alles zelf doen? Bedenk dan goed of je alle expertise in huis hebt. En als je die expertise in huis hebt, of je er als team de tijd voor (of zin in) hebt… Expertise, tijd en zin allemaal in orde? Perfect, dan kun je het helemaal zelf.
Heb je in je team niet de expertise van CI/CD en Progress OpenEdge, de tijd of zin? Dan is het een goed idee om eens vrijblijvend met ons kennis te maken. Vanuit Flusso kunnen we oprecht zeggen dat wij genieten van een goede samenwerking met onze klanten. En daar komen we ook het beste tot ons recht. Vul onderstaand het contactformulier in voor een vrijblijvende kennismaking.
Vertel me meer over je applicatie en hoe we kunnen helpen met Progress OpenEdge werkzaamheden.