mboost-dp1
Udrulning af nyt website
Heay,
Jeg kom til at tænke på hvordan man egentlig i praksis udruller et nyt website istedet for det gamle.
Jeg tænker f.eks. på dengang newz v4 blev lanceret og lignende situationer.
Jeg går ud fra man sidder og udvikling på et subdomain, f.eks. dev.newz.dk eller lignende, men hvad gør man så når man er klar til lancering?
Sletter man bare alle filer fra det normale www dir og indsætter dem fra dev.newz.dk eller retter man bare så newz.dk peger på dev.newz.dk istedet for den normale www folder?
Jeg kom til at tænke på hvordan man egentlig i praksis udruller et nyt website istedet for det gamle.
Jeg tænker f.eks. på dengang newz v4 blev lanceret og lignende situationer.
Jeg går ud fra man sidder og udvikling på et subdomain, f.eks. dev.newz.dk eller lignende, men hvad gør man så når man er klar til lancering?
Sletter man bare alle filer fra det normale www dir og indsætter dem fra dev.newz.dk eller retter man bare så newz.dk peger på dev.newz.dk istedet for den normale www folder?
#3: Why? :p .. der kunne lige så godt have stået et hvilket som helst andet site
Jeg benytter samme metode som arne_v beskriver.. Jeg gad dog godt sommetider have et program, der kunne synkronisere både filer og databaseindhold i et hug. Med mulighed for versionering naturligvis.
Jeg benytter samme metode som arne_v beskriver.. Jeg gad dog godt sommetider have et program, der kunne synkronisere både filer og databaseindhold i et hug. Med mulighed for versionering naturligvis.
Man skal huske at slette alle de gamle filer.
Som simm er inde på, så er database struktur og indhold faktisk en langt større opgave en nogle filer.
Men hvis man kan få en smule nedtid, så man kan arbejde uforstyrret, så er det ike så slemt.
Hvis du f.eks. udvikler til Java EE, så deployer du en .ear fil (en zip fil) og så sørger serveren selv for at fjerne det gamle og udpakke det nye.
Som simm er inde på, så er database struktur og indhold faktisk en langt større opgave en nogle filer.
Men hvis man kan få en smule nedtid, så man kan arbejde uforstyrret, så er det ike så slemt.
Hvis du f.eks. udvikler til Java EE, så deployer du en .ear fil (en zip fil) og så sørger serveren selv for at fjerne det gamle og udpakke det nye.
Til udvikling af newz.dk har vi en udviklingsserver. Den er sat op med trac til håndtering af arbejdsopgaver og SVN til versionering.
Denne har en webproces liggende på test.newz.dk. Hver eneste udvikler har desuden vores egen proces herunder, så vi kan teste vores egne ændringer, inden vi uploader til hele testmiljøet. Jeg har således mine ting på acro.test.newz.dk, hvor jeg tester, inden det kommer videre til test.newz.dk for endelig at blive publiceret til newz.dk.
Databasen versioneres selvfølgelig også, så vi har migreringsjob, der holder den opdateret, og når serveren så opdateres, tømmer den samtidig cachen og udfører de nødvendige ændringer af databasen.
Hvis I har mere konkrete spørgsmål, besvarer jeg også gerne dem.
Denne har en webproces liggende på test.newz.dk. Hver eneste udvikler har desuden vores egen proces herunder, så vi kan teste vores egne ændringer, inden vi uploader til hele testmiljøet. Jeg har således mine ting på acro.test.newz.dk, hvor jeg tester, inden det kommer videre til test.newz.dk for endelig at blive publiceret til newz.dk.
Databasen versioneres selvfølgelig også, så vi har migreringsjob, der holder den opdateret, og når serveren så opdateres, tømmer den samtidig cachen og udfører de nødvendige ændringer af databasen.
Hvis I har mere konkrete spørgsmål, besvarer jeg også gerne dem.
På mit arbejde har vi et deployeringsværktøj, til at flytte programmer/portlets etc op igennem miljøerne.
I praksis fungere det sådan, at udviklerne checker ind og ud af et versioneringsværktøj, når de er klar pakker de sagerne, og uploader dem i et værktøj, herefter kan de deploye til deres komponent-test. Når applikation er færdig der, rykkes den videre til Integration, herefter PreProd og så Prod.
Reinstallation af en pakke, betyder at det gamle indhold slettes.
Denne her metode gør, at har vi et system der crasher, så kan man relativt hurtigt sætte en ny applikationsserver op, og ligge de applikationer på maskinen som der var før, og så kører videre fra hvor man slap.
Desuden er der styring med hvem der må deploye til hvilke miljøer, og der er fingerprint, så det ikke er 'nogen' der har lavet en deployering, men en navngivet person.
I praksis fungere det sådan, at udviklerne checker ind og ud af et versioneringsværktøj, når de er klar pakker de sagerne, og uploader dem i et værktøj, herefter kan de deploye til deres komponent-test. Når applikation er færdig der, rykkes den videre til Integration, herefter PreProd og så Prod.
Reinstallation af en pakke, betyder at det gamle indhold slettes.
Denne her metode gør, at har vi et system der crasher, så kan man relativt hurtigt sætte en ny applikationsserver op, og ligge de applikationer på maskinen som der var før, og så kører videre fra hvor man slap.
Desuden er der styring med hvem der må deploye til hvilke miljøer, og der er fingerprint, så det ikke er 'nogen' der har lavet en deployering, men en navngivet person.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund