Lukket testsystem

[Mellom]

Hei.

 

Skal snart igang med et enkelt webside-prosjekt i forbindelse med jobb. Har lite erfaring fra før, men har blitt spurt om jeg likevel kan teste/leke litt og se hva det ender opp med.

 

Bedrift har ikke egne servere og er avhengig av å leie. Mitt spørsmål er da hvordan dere vanligvis går frem for å ha en lukket testside hvor jeg kan prøve meg frem og holde oppdatert, og hvor ingen kunder el. som søker opp firmanavn får tilgang. Kunne gjort alt lokalt på maskin, men blir vanskelig da ikke databaseverktøy, php ol. er installert.

 

Skal jeg bare koble opp mot ftp som jeg ville gjort vanelig, men legge en basic auth løsning hvor siden er låst for uvedkommende. Eller er det noen andre smarte løsninger og holde siden privat selv om den ligger på server med domene knyttet opp?

[Helvetica]

MAMP har php, MySQL, My Apache etc - og er helt gratis. (i hvertfall basic versjonen)

Jeg har brukt det på OS X, og det fungerte kjempefint. Regner med det fungerer godt på Windows også.

 

http://www.mamp.info/en/

[ahw_]

Utviklere bør jobbe og teste lokalt på egne maskiner, med egne isolerte miljø. Du bør så klart også skrive både unit-tester og integrasjonstester, så kjører du disse i produksjonsmiljøet når alt er klart. Kan være så enkelt som å hviteliste din IP når du skal teste siden i produksjonsmiljøet (i HTTP-serveren). Tilsvarende til det TARDIS nevnte til Windows og Linux er WAMP og LAMP henholdsvis.

 

Jeg synes at *AMP virker litt for... lappet sammen? I stedet for LAMP (på Windows) bruker jeg WampDeveloper, som dessverre koster litt.

 

Til utvikling av nettsider med ASP.NET, er Visual Studio (kanskje også SharpDevelop som er gratis) så og si det eneste du trenger (og SQL Server Express, MySQL, eller tilsvarende). IIS har egen add-on til PHP hvis du trenger dét.

Endret 26. oktober 2014 av ahw_

[etse]

På jobb følger vi følgende system med utvikling:

- Git for versjonskontrollg og deling av kode, med følgende branches:

* Master: Det som til en hver tid skal ut i produksjon

* Develop: Som som kjører på test-servere (mange sider har f.eks. http://beta.minside.com - som da kjører testkoden)

* Feature branches: hver feature-branch har navn med hvilken feature man jobber med. Dette ligger ikke ute i noen testmiljø - og skal merges inn i develop når den er stabil og ferdig.

 

Det som ligger på master-serveren (og er i produksjon) skal til en hver tid være stabilt. Ingenting skal utvikles rett på master branchen, men skal gå via develop som merges inn i master ved hver release. Eneste gangene man kan legge noe rett på master er hvis det er en bugfix som haster å få ut i produksjon.

 

Når man utvikler og tester ut nye ting blir da flowen at man brancher ut av develop og inn i en egen branch hvor du (og de du eventuelt samarbeider med) jobber. Testing av denne koden skjer da lokalt - og man har et eget testmiljø. For enkelhetsskyld holder vi oss unna å bruke apache og slikt her - men i stedet bruker vi Jetty, som gjør det veldig enkelt å sette opp servere lokalt. (man bare kloner git-repository, bygger koden og trykker kjør). Altså slipper man at utviklere som skal jobbe på prosjektet må laste ned og sette opp egne servere selv.

 

Når en feature er fullført setter man opp en pull-request mot develop-branchen. En annen person er da ansvarlig for å behandle denne pull-requesten. (dette kan være hvilken som helst annne utvikler) - og skal da ta en QA av koden din og sørge for å teste at alt fungerer, samt at koden er av akseptabel kvalitet. Når denne er gjort blir koden merget inn i develop og lagt ut på testserveren.

Endret 26. oktober 2014 av etse

[Emancipate]

Kunne gjort alt lokalt på maskin

Det er det du bør gjøre.

[Mellom]

Takk for gode og utfyllende svar!

 

Skjønner at lokal testing blir et must ja, delvis basert på svarene over ser jeg for meg noe slikt:

*Lokal server i form av programvare på primær arbeidsstasjon eller linux på hardware som ikke lenger er i bruk.

*Fortløpende skriving og test via nevnte lokale server.

*Flytte over fullverdige versjoner til offentlig server etterhvert som de kommer til.

 

Bruker forøvrig Mac og har kommet godt inn i programvaren Coda for html/php/css produksjon. Mamp som server ser dermed fristende å sette seg mer inn i for å utvikle lokalt. Takk for tipset!

[hernil]

Sjekk ut Vagrant

[Yawa]

Jeg jobber altid lokalt ved bruk av MAMP. Jeg har kjøpt PRO utgaven slik at jeg kan hoste flere sider lokalt.

Dette gir også muligheten til å la andre maskiner på nettverket koble seg opp mot testserveren slik at man ikke trenger å laste noe opp på produksjonsserveren for at andre skal kunne få tilgang til det som blir utviklet. Faktisk utviklet jeg et helt komplett logistikksystem ved bruk av MAMP server. Med login for alle selgere og montører.

 

Både test og produksjon er identiske. Så hva enn som fungerer lokalt, vet jeg at vil fungere på internett (produksjon) også.

 

Jeg har også opprettet en framework mappe som følger samme mappestruktur som nettstedet ellers. Her har jeg all gjenbrukbar kode som alle nettstedene/applikasjonene kan benytte seg av. På denne måten slipper jeg å duplikere alle php funksjoner, skript, html maler (views) o.l.

Om jeg vil gjøre en funksjon unik for et spesifikt prosjekt, kan jeg bare kopiere den over i prosjektmappen, og den vil da kunne korrigeres uten å påvirke andre prosjekter som benytter seg av denne.

 

Du burde opprette noe lignendes hvis du skal teste og utforske.

Det er håpløst å sitte å ha 5 identiske kopier av samme skript bare fordi du har 5 forskjellige prosjekter/moduler/objekter/applikasjoner på gang...

Endret 26. oktober 2014 av Yawa

[quantum]

 

Du burde opprette noe lignendes hvis du skal teste og utforske.

Det er håpløst å sitte å ha 5 identiske kopier av samme skript bare fordi du har 5 forskjellige prosjekter/moduler/objekter/applikasjoner på gang...

 

Alle plattformer av noen som helst praktisk verdi har vel støtte for å løse sånne problemstillinger automagisk?Tilog med PHP, som man DESVERRE ofte ender opp med om man må leie webhotell, må vel ha noe sånt på plass? De kommer jo haltende etter i sitt eget tempo på en del andre områder, så jeg ville nesten trodd det?

[ahw_]

Alle plattformer av noen som helst praktisk verdi har vel støtte for å løse sånne problemstillinger automagisk?Tilog med PHP, som man DESVERRE ofte ender opp med om man må leie webhotell, må vel ha noe sånt på plass? De kommer jo haltende etter i sitt eget tempo på en del andre områder, så jeg ville nesten trodd det?

Det kommer mer an på om individuelle «nettsider» har rettigheter til å aksessere overmapper i filsystemet. Sannsynligvis har de det, fordi du bare får én bruker som har de samme rettighetene til alt (med unntak) under ditt område. Det er bare når du velger den billige delte løsningen (shared hosting) at du må nøye deg med hva enn du får. VPS (Virtual Private Server) er så mye bedre men koster også mye mer.

Endret 31. oktober 2014 av ahw_

[quantum]

@ahw_ Tror vi kanskje snakker om to ulike problemer?

 

Jeg forstod det som problemet var duplisering og vedlikehold av script med fellesfunksjonalitet i ulike prosjekter/moduler. Dette løser man f.eks. med npm i Node.js-verden, Maven i Java-verdenen osv. Antar man har fått stablet noe tilsverende på beina i PHP-verdenen, f.eks. Composer, kanskje. Det hele er snudd litt "på hodet" dersom det er driftsmiljøet som skal styre dette.

Endret 2. november 2014 av quantum

[etse]

Skriver man god PHP-kode, så skal det vel i likhet med alt annet kode som skal ut i produksjon helst være testbar. Dette betyr jo at man ikke nødvendigvis trenger å fyre opp server og nettleser bare for å se om funksjonalitet man har implementert faktisk funker - men i stede kan man bare kjøre unit-testene og se om de passerer.

 

Personlig synes jeg det er en uting å måtte åpne opp en nettside bare for å sjekke om logikk funker. Og så godt det lar seg gjøre prøver jeg å unngå det så lenge jeg ikke jobbet med selve viewet.

[ahw_]

@ahw_ Tror vi kanskje snakker om to ulike problemer?

 

Jeg forstod det som problemet var duplisering og vedlikehold av script med fellesfunksjonalitet i ulike prosjekter/moduler. Dette løser man f.eks. med npm i Node.js-verden, Maven i Java-verdenen osv. Antar man har fått stablet noe tilsverende på beina i PHP-verdenen, f.eks. Composer, kanskje. Det hele er snudd litt "på hodet" dersom det er driftsmiljøet som skal styre dette.

Det jeg mente var at problemstillingen er nærmest likegyldig så lenge nevnte forutsetninger er på plass, noe de mest sannsynlig vil være selv med billige webhotell (delt løsning). Problemet lar seg løses relativt enkelt både med og uten Composer – og ikke alle biblioteker finnes i systemet.

 

Selv om Composer ikke er installert allerede på serveren, kan man forsøke å laste ned Composer selv. Uansett bør man strengt tatt ikke installere eller oppdatere pakker uten å ha testet først lokalt.

[quantum]

Som sagt - dette er ikke en problemstilling man søker å løse på serveren/webhotellet, eller tar jeg feil? Du bygger deploymentet på en arbeidsstasjon, eller integrasjonsserver, og får det lastet opp til det aktuelle kjøremiljøet med avhengigheter inkludert.

 

Det er ønskelig å kunne installere moduler i pakkerepositoryet selv, både fellesmoduler som ikke fins i sentralt repository og de modulene man selv programmerer, slik at man lett kan benytte disse i flere egne prosjekter uten å ha identisk kildekode som må vedlikeholdes flere steder.

 

Mulig PHP-miljøet ikke har verktøy som kan løse dette på en brukbar måte.

Endret 2. november 2014 av quantum

[Yawa]

Hva enn man måtte trenge av filer o.l. må være lagret et eller annet sted, og det er jo helt individuelt hvordan man velger å få tilgang til disse. Ved bruk av Composer, så laster man i bunn og grunn ned/flytter over en kopi, av den aktuelle modulen man vil benytte, til prosjektmappen fra en eller annen definert plassering. Til eksempel fra en "framework"-mappe, eller et bibliotek man har bygget opp selv. Med andre ord så oppretter man en ny kopi av de nødvendige filene for hver gang man benytter seg av den enkelte modulen.

 

Dette tar opp unødvendig plass, og skaper unødvendig arbeid når man foretar en modifisering/oppdatering av den enkelte modulen..

 

Jeg setter opp en del nettsider, og som nevnt tidligere, så gjør jeg dette lokalt før jeg flytter det hele over til en produksjonsserver - et eksternt webhotell på nett...

Det er kun når jeg flytter nettstedet opp på den eksterne serveren at det skapes kopier av nødvendige filer. Disse filene hentes da fra "framework"-mappen/biblioteket mitt på min lokale server.

[quantum]

Pussig, jeg ville nesten trodd formålet med Composer var å redusere arbeidsmengde, ikke øke. Og argumentet med diskplass ... øh, ja, et koderepo tar plass, men det er en grunn til at man ønsker å ha det ... velvel, som du sier er det helt individuelt hvordan man ønsker å jobbe.

[ahw_]

Pussig, jeg ville nesten trodd formålet med Composer var å redusere arbeidsmengde, ikke øke. Og argumentet med diskplass ... øh, ja, et koderepo tar plass, men det er en grunn til at man ønsker å ha det ... velvel, som du sier er det helt individuelt hvordan man ønsker å jobbe.

Tingen er nok at man skal ha muligheten til å benytte en spesifikk versjon av f.eks. et rammeverk, som følger ett enkelt prosjekt. Vil man dette, bør man ha Composer & Co. liggende sammen med prosjektet i stedet for et felles sted. Man slipper altså å teste alle sine andre prosjekter på nytt dersom man oppdaterer noe med Composer.

 

Bruker man Git submodules får man en ganskel lik funksjonalitet. Jeg foretrekker forresten dette fordi man kan oppdatere ting helt uavhengig av andre prosjekter, og man får mye annet snacks med.

 

Likevel ønsker man ofte å ha bare én kopi av et rammeverk eller bibliotek, så da kan man plassere Composer-greiene på et felles sted. Kanskje man t.o.m. kan ta i bruk flere enn én Composer-installasjon, men det vet jeg ikke.

 

Personlig synes jeg det beste er Git-måten jeg nevnte. Den bruker jeg til alt, med noen unntak der kompilering av store biblioteker kan ta en halv time å fullføre.

[quantum]

Tingen er nok at man skal ha muligheten til å benytte en spesifikk versjon av f.eks. et rammeverk, som følger ett enkelt prosjekt. Vil man dette, bør man ha Composer & Co. liggende sammen med prosjektet i stedet for et felles sted. Man slipper altså å teste alle sine andre prosjekter på nytt dersom man oppdaterer noe med Composer.

 

 

 

Man må absolutt ha styring på avhengighetene og versjonene av disse man trekker inn i prosjektet, helt enig. Hvis ikke Composer kan håndtere flere versjoner av samme modul i et repository blir det litt kleint ... men jeg fikk jo inntrykk av at ihvertfall dét håndteres da jeg googla. Bruker maven og nexus sammen med jenkins til bygging, og forsåvidt git til versjonshåndtering, men uten å behøve å bruke submodules.

[Gjest Slettet-x7D6du0Hjb]

Hei.

 

Skal snart igang med et enkelt webside-prosjekt i forbindelse med jobb. Har lite erfaring fra før, men har blitt spurt om jeg likevel kan teste/leke litt og se hva det ender opp med.

 

Bedrift har ikke egne servere og er avhengig av å leie. Mitt spørsmål er da hvordan dere vanligvis går frem for å ha en lukket testside hvor jeg kan prøve meg frem og holde oppdatert, og hvor ingen kunder el. som søker opp firmanavn får tilgang. Kunne gjort alt lokalt på maskin, men blir vanskelig da ikke databaseverktøy, php ol. er installert.

 

Skal jeg bare koble opp mot ftp som jeg ville gjort vanelig, men legge en basic auth løsning hvor siden er låst for uvedkommende. Eller er det noen andre smarte løsninger og holde siden privat selv om den ligger på server med domene knyttet opp?

 

 

Har du hørt om Wampserver? Funker helt utmerket for web utvikling.

 

http://www.wampserver.com/en/