Sovelluskehitys tuotantoympäristössä

  • Keskustelun aloittaja Keskustelun aloittaja ©©©
  • Aloitettu Aloitettu
Liittynyt
16.10.2016
Viestejä
544
Tässä topicissa voitaisi jakaa omia kokemuksia, vinkkejä ja ohjeita tuotantoympäristöjen pyörittämisestä. Kaikki keskustelu tervetullutta miten pärjätä isojen ja pienten projektien kanssa joilla on oikeita käyttäjiä ja seuraamuksia. Myös kaikki ryhmänhallinta-, organisaatio-, prosessi-, hr-, yms. jutut tervetulleita, eikä keskustelua pelkästään teknologiasta. Itse toimin eräänlaisessa tech lead roolissa globaalissa yrityksessä, jossa vedän teknologiakehitystä monipilviympäristöissä. Olisi tosiaan kiva kuulla muidenkin kokemuksia ja jakaa tietoa täällä.

Omat muutamat sentit:
  • Versiohallinta. Kaikki vähänkään vakavammat softaprojektit tarvitsevat jonkinlaisen versiohallinnan. Tämä on yleensä koko projektin kulmakivi minkä ympärillä kaikki pyörii. Itsellä hyviä kokemuksia ihan perinteisestä GitHubista.
  • Tehtävänhallinta. Issueiden ja taskien hallinta ja työnsuunnnittelu. Yleisempiä on varmaan Jira ja GitHub. Meillä pyörii kaikki GitHubissa aina projektin boardista issueihin ja sprinttien suunnitteluun. Palveluhallinta käyttää Jiraa koska sen ei tarvitse olla niin sidoksissa koodiin.
  • Julkaisumenetelmät. CI/CD nyt varmaan tulee kaikilla ensimmäisenä mieleen kun puhutaan tuotantokoodin julkaisemisesta tuotantoalustalle. CI/CD käytännössä tarkoittaa automaattista ja integroitua julkaisujärjestelmää jonka avulla voidaan tehdä luotettavasti tuotantojulkaisu.
  • Testaus. Automaattinen testaus on yleensä sidoksissa CI/CD-putkeen joka siis testaa ohjelmiston toimivuuden automaattisesti. Hyvin tärkeä osa-alue tuotantoympäristöissä.
  • Dokumentointi. Dokumentointia voidaan tehdä monella eri tavalla ja tasolla. Koodia pitää dokumentoida mm. JSDoc on näppärä työkalu Javascript-koodin kommentointiin ja dokumentointiin. Lisäksi tarvitaan ylemmän tason dokumentointiratkaisuja kuten GitHubissa ihan vaan readme.md ja wiki-ratkaisut. Myös tuotantoversioiden julkaisu pitää dokumentoida, mitä julkaistaan.
  • Koodin tyylisäännöstö. Vaikka devaajia olisi ihan muutama on todella hyvä idea asettaa yhtenäinen tyylisäännöstä koodille joka formatoi sen samaan muottiin. Esim. ESLint ja prettier ovat hyviä työkaluja.
  • Infra. Eli siis IaC, pilvet, kontit, infra-alustat. Hyvin toimiva koodi ei ole mitään ilman hyvin toimivaa infraa. Infrapuolella on tapahtunut ihan huikeita muutoksia viime vuosina. Kontit, pilvet ja palvelittomat ratkaisut ovat melkolailla standardia nykyään kun puhutaan modernista tavasta tehdä infraa. Me ollaan mm. hyödynnetty GCP Kubernetesta. Teen paljon myös hommia Terraformin kanssa VMware-alustoille.
  • Automaatio. Kaikenlainen manuaalinen säätäminen on aina ihan hirveetä tuotannossa. Tästä syystä onkin hyvä idea automatisoida mahdollisimman paljon asioita tuotannossa. Ihmiset tekevät aina virheitä ja ovat hitaita ja raskaita tekemään mitään. Kun kerran panostaa jonkin asian automatisoimiseen niin se maksaa kyllä itsensä aina takaisin.
  • Tietoturva. Tänä päivänä on erittäin tärkeää huolehtia tietoturvasta kaikessa tekemisessä devaajasta toimariin. Palvelun tai jopa koko yrityksen uskottavuus ja tulevaisuus on vaakalaudalla mikäli tietoturva ei ole kunnossa. Tähän ei ole mitään yksittäistä vastausta koska aihe on niin laaja. Yksi tapa on ulkoistaa joitakin teknisiä tietoturvapalveluita kuten lokienhallinta ja SOC niille erikoistuneille yrityksille kuten vaikka Nixu.
 
Mites konfiguraationhallinta? Kuinka hallita koko stackin laajuista konfiguraatiota siten, että kukin deploymentti menee sisään sitä vastaavilla konfiguraatioilla? Ehdottomasti aihealue joka etenkin tuotekehityksessä tulee eteen kun aletaan puhua useammista asiakkaista omilla konfiguraatioillaan.

Itselläni on HashiCorpin Consulista ihan positiivisia kokemuksia. Devauksen aikana mahdollistaa konfiguraatioiden päivittämisen lennosta ja toisaalta kutakin testiympäristöä vastaava konfiguraatio on helpohko kopioida lokaaliin Consul-instanssiin. Myös service discoveryn käytöstä Consulin kautta on ihan positiivisia kokemuksia.

Itse konfiguraatioiden hallintaan on kokemusta talon sisäisesti kehitetystä järjestelyssä, jossa gittirepoon on määritelty koko deploymenttiin sisältyvät servicet (dockerit) sekä niitä vastaavat konfiguraatiot. Kullekin sovellukselle (joita deploymentissa on useita kymmeniä) löytyy oma konfiguraatio jonka sisältö voidaan validoida sovelluskohtaista konfiguraatioschemaa vasten.
 
Entäs katselmoinnit?

Automaattinen testaus koetaan tässä riittäväksi.

Testaushan on aina siitä kiinni, paljon aikaa/resursseja tähän on laittaa. Monta henkilöä tunnin katselmoimassa ja siinä on helposti mennyt henkilötyöpäivä.
 
Entäs katselmoinnit?
Meillä menee jokainen commit code reviewin läpi ja isommat kokonaisuudet katselmoidaan pitkin toteutusta. Just oli keissi jossa jouduttiin tekemään massiivinen katselmointi ulkopuolisen konsultin tuotoksiin ja siihen paloi tuhottomasti aikaa. Parempi tsekata tuotoksia pienissä erissä eikä könttänä kun homma on ns. valmis.
 

Statistiikka

Viestiketjuista
261 320
Viestejä
4 535 117
Jäsenet
74 789
Uusin jäsen
anykanen

Hinta.fi

Back
Ylös Bottom