Feature Flags: Si ndryshon software-i pa pritur versionin tjetër?

Jemi mësuar që një funksionalitet i ri të vijë bashkë me një version të ri të software-it. Përditësohet aplikacioni, publikohet versioni dhe ndryshimi bëhet i disponueshëm.

Por software-i modern nuk funksionon gjithmonë kështu.

Një funksionalitet mund të jetë tashmë pjesë e versionit që ndodhet në production dhe megjithatë të mos jetë ende aktiv. Mund të hapet fillimisht vetëm për ekipin që po e zhvillon, më pas për një grup të vogël përdoruesish dhe, në fund, për të gjithë.

Madje, nëse shfaqet një problem, mund të çaktivizohet pa qenë gjithmonë e nevojshme të publikohet menjëherë një version tjetër.

Pas këtij fleksibiliteti qëndron një mekanizëm i quajtur Feature Flags.

Kodi mund të jetë gati. Release-i mund të presë.

Ideja bazë është relativisht e thjeshtë.

Një Feature Flag funksionon si një shtresë kontrolli mbi një funksionalitet të caktuar. Kodi mund të jetë vendosur tashmë në production, por flag-u përcakton nëse funksionaliteti duhet të jetë aktiv apo jo.

Kjo ndan dy momente që tradicionalisht kanë qenë shumë të lidhura: vendosjen e kodit në production dhe publikimin e funksionalitetit te përdoruesit.

Për ekipet e zhvillimit, kjo krijon më shumë fleksibilitet. Një version i ri nuk duhet domosdoshmërisht të presë derisa çdo funksionalitet brenda tij të jetë gati për t’u hapur për të gjithë.

Dhe një funksionalitet nuk duhet domosdoshmërisht të presë versionin tjetër vetëm sepse momenti i publikimit të tij ka ndryshuar.

Jo çdo ndryshim duhet të shkojë menjëherë te të gjithë

Një nga përdorimet më praktike të Feature Flags është aktivizimi gradual.

Një funksionalitet i ri mund të hapet fillimisht për ekipin e brendshëm. Më pas për një numër të kufizuar përdoruesish dhe, nëse gjithçka funksionon siç duhet, gradualisht për një pjesë më të madhe.

Kjo i jep ekipit mundësinë të shohë se si sillet funksionaliteti në kushte reale pa ekspozuar menjëherë të gjithë përdoruesit ndaj ndryshimit.

Në vend që release-i të jetë një kalim i menjëhershëm nga 0% në 100%, ai mund të bëhet një proces i kontrolluar.

Një problem nuk duhet të nënkuptojë gjithmonë një version tjetër

I njëjti kontroll funksionon edhe në drejtimin e kundërt.

Nëse pas aktivizimit shfaqet një problem, një funksionalitet i menaxhuar përmes Feature Flags mund, në raste të përshtatshme, të çaktivizohet pa pritur një cikël të ri release-i.

Kodi vazhdon të jetë aty, por përdoruesit nuk ekspozohen më ndaj funksionalitetit problematik.

Kjo nuk zëvendëson testimin, rollback-un apo praktikat e tjera të sigurisë së software-it. Por krijon një mundësi shtesë për të reaguar shpejt dhe për të kufizuar ndikimin e një problemi.

Nga publikimi i versioneve te kontrolli i ndryshimeve

Feature Flags nuk e eliminojnë release-in dhe as nevojën për versione të reja. Ato ndryshojnë mënyrën se si një funksionalitet kalon nga kodi te përdoruesi.

Ekipi mund të vendosë kodin në production dhe më pas të kontrollojë veçmas kur aktivizohet funksionaliteti, kush e merr dhe sa gradualisht bëhet i disponueshëm.

Siç shprehet Ermal Beqiri, themelues i Soft & Solution Group:

“Me Feature Flags, një funksionalitet mund të jetë gati dhe pjesë e software-it, pa qenë nevoja të aktivizohet menjëherë për të gjithë. Kjo u jep ekipeve më shumë kontroll mbi mënyrën si publikohen ndryshimet dhe mundësinë të reagojnë shpejt nëse diçka nuk shkon siç duhet.”

Software-i mund të evoluojë gradualisht, ndërsa ekipi ruan kontrollin mbi çdo hap të ndryshimit.