Fordelene ved å bruke et Build Framework

Continuous Integration (CI) og/eller Continuous Delivery (CD) er normen på programvareprosjekter i dag. Det finnes mange build-servere som Azure DevOps, TeamCity, Jenkins og Cruise Control.Net. De fleste av disse serverne bruker proprietære språk for å definere build-trinn. Men er det en god ting å kodifisere build-trinnene dine i et proprietært språk?

Noen applikasjoner er enkle, med få build-trinn, andre er mer komplekse med mange build-trinn. Når du definerer build-trinn i et proprietært språk, jo mer komplekse build-trinnene er (i sofistikering eller i antall), jo mer koblet til en build-plattform blir du. Dette blir et problem når du vil bytte build-plattformer. For eksempel bruker du JetBrains TeamCity i ditt on-premise datasenter, men selskapet bestemmer seg for å flytte til skyen. Nå må du omskrive build-skriptene dine fordi TeamCity ikke støttes på den nye skyen.

I stedet for å skrive build-skriptene dine i et proprietært språk, bør du vurdere å bruke et build framework.

Build frameworks har to fordeler:

1. Tillater portabilitet mellom build-plattformer.
2. Tillater deg å versjonere build-skriptene dine sammen med applikasjonskoden din.

Portabilitet mellom plattformer gir deg fleksibiliteten til å flytte mellom build-plattformer med minimal innsats. Det vil alltid være noe konfigurasjon på en ny build-plattform, men build frameworks holder innsatsen lav.

Etter min mening er den største fordelen med build frameworks muligheten til å sjekke inn og versjonere build-skriptene dine sammen med applikasjonskoden din. Å ha muligheten til å hente kode fra et hvilket som helst punkt i kildekontrollen din og ha at koden bygges, er det verdt eventuelle ulemper ved et build framework.

Det finnes to populære frameworks i .Net-området: Cake og Nuke Build. Begge frameworks har vært rundt en stund. Jeg har brukt Nuke Build og liker det. Jeg har hørt flotte ting om Cake og oppfordrer deg til å se på det før du bestemmer deg for hvilket framework som er best for prosjektet ditt.

Så neste gang du oppretter en ny build-definisjon for applikasjonen din, bør du vurdere å bruke et build framework og sjekke det inn i kildekontrollen sammen med applikasjonen din.