Utvecklingsmiljö på jobbet

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
ollu's picture

Hej,

Vi funderar på att uppgradera vår lokala utecklingsmiljö här på Kodamera. Vi har under ett antal år kört med en gemensam Server där varje utvecklare har haft sin egna mapp som hen klonar ut filer från git till. Mappen är sen åtkomlig via en apache vhost-regel så att det blir ungefär http://projekt.mappnamn.kodamera.dev/.
Vi har dock på senare tid börjat uppleva att det går väldigt långsamt och då framförallt för MySQL. Databasen ligger på samma server som apache och vi delar alla på samma databaser. Vilket har sina för-/nackdelar men det har oftast fungerat bra.

Så nu funderar vi på andra alternativ ...
* Lokal utvecklingsmiljö på Vagrant-box, delad databas-server
* Lokal utvecklingsmiljö på Vagrant-box med egen databas som vi synkar med hjälp av t ex Features.
* Fetare server för att klara av alla databaskopplingar.

Så till min fråga, är det någon som har ett arbetssätt som fungerar eller som de kan rekommendera? Eller bara åsikter på våra funderingar.

Ha det gott, Ola

Comments

Låter som att det enklaste

pontus.froden's picture

Låter som att det enklaste vore att flytta databasen till en egen server, som dimensioneras efter behovet.

Det vill säga om ni trivs med nuvarande arbetsflöde.

Fördelen, som jag ser det, med en central punkt är att det underlättar backuper. Lokala Vagrant miljöer kan vara lite krångligare att göra kontinuerliga backuper på. Fördelen är ju att de alltid har med sig miljön om de arbetar på annan plats ibland.

Vagrant

pontus_nilsson's picture

Vi jobbar med Vagrantboxar. För varje projekt i git följer det med en Vagrantfile som säger vad sajten kommer heta lokalt och IP till den ihop med ansible instruktioner för hur servern ska sättas upp.

När någon ny tillkommer till projektet så gör de en git clone, vagrant up och drush site-install så är de igång. Det som är bra med detta är att varje miljö kan ställas in att vara lika som målmiljön. En del av våra boxar är centos andra ubuntu osv.
Vissa boxar har Solr, Elasticsearch etc uppsatt på samma sätt som produktionsmiljön har. Då blir det enkelt att lokalt sitta och testa olika inställningar för t.ex. Solr och sedan commita in de ändringar som ska göras till produktion.

Nackdelen är att vagrant är en en virtuell maskin vilket gör att det inte blir lika snabbt som om du kör en webbserver lokalt. Docker finns som alternativ för dem som sitter på Linux.

Vi jobbar på ett sätt så att våra projekt alltid går att installera om från start. Vi är alltså inte boroende av databasen från produktion (förutom om det är just felsökning av content).

Ifall sajten behöver något innehåll för att den ska fungera av någon anledning så skapas det under installation av sajten.
På så sätt kan vi t.ex. bygga om en innehållstyp genom att första installera om, bygga om något fält eller vad som ska ändras, sedan göra migreringsjobb. Med ett drush site alias kan man hämta produktions/stage-databas och testa att sin updatehook lirar som den ska.
I och med att all konfiguration finns i kod så blir det också lätt att göra en deploy utan att oroa sig för manuella deploysteg och man kan också se vad som gjorts i git. När en deploy är gjord till t.ex. stage server och godkänd av kunden så är nästa deploy till produktion ett klick bort. När koden finns i git och nästa utvecklare sätter igång så kommer de också få de ändringar som gjorts via drush updb men kan fortfarande jobba med sin lokala databas.

//Pontus Nilsson, Digitalist

Tack för input!

ollu's picture

Ska försöka dela med mig av vart vi landar när vi väl är där.