Producerea unor release notes corecte și consecvente într-un mediu de producție modern este surprinzător de dificilă. Echipele de dezvoltatori gestionează în mod obișnuit patru sau mai multe sisteme deconectate: Jira pentru urmărirea sarcinilor, GitHub Enterprise pentru pull requesturi, baze de date Oracle pentru modificări de schemă și Confluence ca destinație canonică de publicare - fără niciun instrument care să le integreze simultan. Rezultatul este un proces manual, predispus la erori, care întârzie lansările, produce documente inconsistente și consumă timp prețios de dezvoltare cu muncă de rutină. Acest articol prezintă Release Notes Automation, un lanț intern de instrumente care elimină complet acest proces, bazat pe o arhitectură pe trei layere: un generator CLI în Java 17, microservicii Spring Boot de tip MCP(Model Context Protocol) și un Wizard de introducere a datelor găzduit pe GitHub Pages.
În cadrul Direcției Soluții Channels și Retail a Băncii Transilvania, livrarea unei versiuni de produs nu se termină odată cu merge-ul ultimului pull request. Pentru fiecare release trebuie produs un artefact suplimentar, adesea subestimat, dar important pentru lansare, audit și comunicarea cu părțile interesate non-tehnice: pagina de release notes publicată în Confluence. Acest artefact consolidează, într-o formă lizibilă, taskurile Jira închise, pull requesturile incluse, modificările de schemă din baza de date Oracle și metadatele de deployment, devenind sursa unică de adevăr pentru ceea ce a intrat efectiv în versiunea respectivă.
Ecosistemul tehnologic în care această activitate se desfășoară este unul tipic Enterprise: GitHub Enterprise, Jira, Oracle Database și Confluence - toate protejate de politicile corporative de securitate, cu acces prin proxy, tokenuri cu durată de viață limitată și segregare strictă pe echipe. În absența unei integrări dedicate, producerea unei singure pagini de release notes presupune un flux manual: un dezvoltator deschide simultan patru ferestre de browser, filtrează manual tichetele Jira, listează pull requesturile dintre două taguri în GitHub, rulează scripturi ad-hoc peste dicționarul Oracle și copiază manual rezultatele într-un șablon Confluence. Procesul consumă timp, produce inconsistențe între echipe, erori de omisiune și cuplaj între dezvoltator și mediul local.
Soluția propusă este organizată pe trei layere care cooperează:
Generator CLI (Command Line Interface) în Java 17 - orchestrează un pipeline de colectare a datelor în șapte pași și redă rezultate structurate prin șabloane Mustache. Acesta reprezintă coloana vertebrală a automatizării, de la descoperirea repository-urilor de proiect sau modificările la nivel de bază de date până la publicarea paginii Confluence.
Microservicii Spring Boot de tip MCP - ridicate pe un server central dedicat, care expun un API unificat pentru GitHub Enterprise, Jira, Confluence și Oracle. Fiecare microserviciu implementează un set de unelte (tools) cu o interfață uniformă: POST /tools/{tool} cu un payload JSON, răspunzând cu un ToolResponse standard.
Wizardul de introducere a datelor bazat pe browser, găzduit pe GitHub Pages, permite oricărui membru al echipei să conducă procesul dintr-o singură interfață, fără a instala nimic local. Wizardul comunică printr-un limbaj standard cu backendul: POST /proxy/{server}/tools/{tool}, prin intermediul bridge-ului Node.js.
Bridge-ul Node.js (bridge-server/index.js) este componenta intermediară dintre wizardul din browser și cele patru microservicii MCP. Acesta rulează pe portul 443, prin HTTPS, și îndeplinește trei roluri: terminarea TLS (Transport Layer Security - nginx gestionează certificatele, bridge-ul servește plain HTTP intern pe portul 7100), validarea tokenului intern propagat de la wizard și rutarea cererii către microserviciul corespunzător pe baza headerului X-Team. Niciun microserviciu MCP nu este expus direct în rețea - la nivel de firewall este deschis exclusiv portul 443.
Modelul de acces este centrat pe utilizatori generici per echipă: fiecare echipă dispune de un set de credențiale partajate, stocate ca profil în browser, cu care se conectează direct la microserviciile MCP centralizate pe server intern BT. Acest design elimină necesitatea ca fiecare dezvoltator să ruleze servicii local, asigurând disponibilitate continuă și un singur punct de configurare.
Fluxul începe când un utilizator accesează Wizardul din browser și se termină când pagina de release notes este publicată în Confluence:
Colectarea pull requesturilor din GitHub Enterprise pentru versiunea respectivă, prin unealta listPullRequests.
Căutarea tichetelor Jira cu fixVersion setat, prin unealta searchIssues.
Detectarea modificărilor de schema în baza de date Oracle, prin unealta listChanges care rulează scripturi SQL.
Descoperirea automată a șablonului prin citirea structurii unei pagini Confluence existente.
Compilarea informațiilor într-o pagină de release notes folosind șabloane Mustache.
Alegerile tehnice au fost ghidate de compatibilitatea dintre cerință și unealtă, nu de uniformitate cu orice preț. Spring Boot cu Java 17 a fost ales pentru microserviciile MCP, deoarece acestea realizează operațiunile intensive: interogări Oracle prin JDBC (Java Database Connectivity), parsarea răspunsurilor paginate din GitHub Pull Requests și generarea de XHTML conform schemei Confluence Storage Format. Node.js deservește bridge-ul, al cărui rol este pur orientat spre I/O: terminarea TLS, validarea tokenului și propagarea unui corp de răspuns JSON. Un proces Node.js cu Express ocupă sub 50 MB RAM și pornește în mai puțin de o secundă.
Descoperirea automată a șabloanelor funcționează prin citirea structurii unei pagini Confluence existente și adaptarea dinamică a formularului în funcție de echipă. Învățarea convențiilor din datele istorice reduce treptat necesitatea introducerii manuale a informațiilor; sistemul recunoaște tipare din release-urile anterioare și pre-populează câmpurile relevante în mod inteligent.
Deploymentul containerizat permite rularea în rețea internă fără acces la registre publice, prin transferul offline al imaginilor Docker.
Release Notes Automation demonstrează cum un protocol uniform (MCP), combinat cu arhitectura pe layere și containerizare, poate elimina munca manuală repetitivă într-un ecosistem Enterprise fragmentat. Designul prioritizează siguranța (tokenuri per echipă, fără credențiale locale pe mașina de lucru a dezvoltatorului), modularitate (tools protocol extensibil prin adăugarea de metode publice) și accesibilitate (wizard browser, fără instalare locală). Compromisurile asumate - șabloane prestabilite, lipsa versionării - reprezintă un consens explicit între scopul MVP (Minimal Viable Product) și ușurința de deployment. Soluția este azi operațională pe un server intern BT și deservește două echipe din cadrul Direcției Soluții Channels și Retail a Băncii Transilvania.
de Mihai Matei
de Bogdan Maier
