workflow in team

[pina]

Hallo,

we hebben op het werk enkele statische websites die op een gedeelde server staan waar iedereen aan kan. Probleem echter is, dat we al enkele keren zijn tegengekomen dat 2 personen tegelijkertijd een index.htm bestand aan het bewerken zijn, met alle gevolgen van dien.

ik heb proberen te zoeken naar een mogelijkheid in Dreamweaver, dat je kan in- en uitchecken van bestanden maar dat werkt enkel wanneer je enerzijds lokaal een site definieert en anderzijds op de remote server. Lokaal is dus eigenlijk onze gedeelde server, waar we rechtstreeks op werken, maar dan kan je niet in- en uitchecken. Dus DW is geen optie...

het andere is Git, maar dat werkt dan over het internet, dus moet je al die sites uploaden naar hun server, wat dan ook niet de bedoeling is.

Zijn er hier die nog andere tools of oplossingen kennen?

[Caelorum]

Een git server kan je gewoon lokaal in het bedrijfsnetwerk draaien. Sterker nog, je hebt niet eens een centrale server nodig. Wat jij waarschijnlijk hebt gevonden is Github of bitbucket oid. Dat zijn diensten die een centrale server opzetten voor je uit handen nemen.

Ik zou eens goed git-scm docs doornemen doornemen of als je dat teveel werk vind kijken naar een dienst als gitlab

[ Voor 26% gewijzigd door Caelorum op 08-05-2015 20:01 ]

[Boelie-Boelie]

pina schreef op vrijdag 08 mei 2015 @ 19:40:
Lokaal is dus eigenlijk onze gedeelde server, waar we rechtstreeks op werken

Als het een NAS is, kun je een Git-app installeren; dan hou je alles intern.

het andere is Git, maar dat werkt dan over het internet, dus moet je al die sites uploaden naar hun server, wat dan ook niet de bedoeling is.

Wat zijn jouw bezwaren hiertegen?

Wel vermoed ik dat het gebruik van Git louter voor het voorkomen van gelijktijdig werken misschien wat overkill is. Als je bijvoorbeeld een Yammer-groep of een Hipchat-room maakt waarin iedereen meldt welke pagina hij momenteel bewerkt of daarna klaar is met bewerken (dus: paginalink bij start, 'done' bij klaar), heb je het ook opgelost. Of een Trello-bord waarin je de te bewerken pagina van een kolom 'backlog' naar een kolom 'in progress' en later 'done' plaatst.

M.a.w. je hoeft er niet per se een ingewikkeld stuk techniek (en bijbehorende processen) voor in te zetten, soms is het slechts het gebrek aan communicatie waar je een kleine proceswijziging in hoeft door te voeren.

[ShitHappens]

Waar je ook naar zou kunnen kijken, is SVN, wordt op kleinere schaal vaker gebruikt. Maar inderdaad ook overkill als je het gewoon communiceert. Wellicht is het prima mogelijk werkzaamheden af te stemmen dat maar 1 persoon tegelijk een bestand nodig heeft.

[Ramon]

Ik ben het niet met de mensen boven mij eens dat git overkill is. Zeker in dit geval waar meerdere mensen aan dezelfde bestanden werken is het ideaal. Zelfs al ben je in je eentje en doe je één commit per maand, dan nog is het altijd handig om te weten wat er wanneer is gewijzigd en waarom én dat je ergens een kopie van je data hebt (in geval van harddisk falen bijvoorbeeld).

Met git, als er twee of meerdere mensen aan hetzelfde bestand hebben gewerkt krijg je hier gewoon een melding van en krijg je een dialoog te zien waar je kan kiezen wat je wilt behouden en wat niet. Git kan overigens zelf in gevallen waar wijzigingen niet dezelfde regel raken de wijzigingen zelf samenvoegen zonder dat jij of iemand anders hoeft te beslissen!

Ik snap verder niet helemaal hoe de statische websites draaien. Draaien deze enkel op jullie gedeelde (lokale) server en komen ze niet terecht op een server die aan het internet hangt? In zo'n geval moet je de website dus ontwikkelen op jullie eigen lokale machine en daarna kan je je wijzigingen committen en pushen en dan naar de server toe gaan en een 'git pull' uitvoeren. Er zijn ook allerlei tools beschikbaar om dit te automatiseren.

BitBucket is gratis tot 5 gebruikers dus ideaal om mee te experimenteren. Je kan bijvoorbeeld SourceTree gebruiken als git UI. Wil je verder automatiseren dan kan je voor een beetje geld beanstalk proberen, hier heb je repository-hosting zoals bitbucket + deployments die je helemaal kan automatiseren.

Je kan inderdaad lokaal een git server installeren maar voordat je dat gaat doen zou ik eerst met bitbucket experimenteren.

[Zoefff]

ShitHappens schreef op zaterdag 09 mei 2015 @ 01:17:
Waar je ook naar zou kunnen kijken, is SVN, wordt op kleinere schaal vaker gebruikt. Maar inderdaad ook overkill als je het gewoon communiceert. Wellicht is het prima mogelijk werkzaamheden af te stemmen dat maar 1 persoon tegelijk een bestand nodig heeft.

Een VCS, of dat nou Git, SVN of een ander systeem is, is nooit overkill. In teamverband zeker niet, maar ook voor mijn eigen projecten gebruik ik gewoon SVN zodat je keurig bijhoudt wat er aangepast is en eventueel naar vorige revisies kan kijken. De kosten en / of tijdsinvestering zijn zo laag en de winst zo groot dat je echt geen enkel argument kan verzinnen om geen gebruik te maken van versiebeheer

[Glodenox]

Inderdaad, enige vorm van versiebeheer is een must bij elk programmeerproject. Als je wilt kijken "waarom in godsnaam werd dit aangepast?" kijk je gewoon in de logs en zie je de reden in de commentaar bij de commit (best deze commentaar verplicht maken, dat helpt enorm). Ook handig om te kijken wie er wat stuk heeft gemaakt, dan kan je deze persoon meteen ook vragen het op te lossen - zo leert die er nog iets van.

Daarnaast kan je op deze manier een grondige vorm van release management toepassen en zelfs automatische deployments in bepaalde omgevingen met behulp van buildservers die automatisch ook je code eerst testen vooraleer deze online wordt gezet/de applicaties gebuild worden. En dan hoef je niet in de bestanden van de server te kijken om te weten welke versie er online staat. Je hoeft enkel te weten wat het versienummer is dat op de server staat en dan weet je alles. Ook qua beveiliging van je website kan dit tellen. Als je wilt voorkomen dat er meer dan 1 persoon tegelijk zaken op de productiewebsite zet, kan je gewoon onderling afspreken dat slechts 1 persoon een versie online kan zetten.

Waar ik werk gebruiken we volop SVN en hebben we release managers die nieuwe versies van onze applicaties online zetten nadat wij dit aanvragen. Hierdoor hoeven wij ons niet bezig te houden met vragen als "op welke servers zetten we dit" en de communicatie met de externe partners. Zo kunnen wij ons volledig focussen op de applicaties zelf.

Kortom: zeker naar versiebeheer kijken en misschien kijken naar het automatiseren van het geheel (continuous integration). Projecten als Jenkins kunnen hierbij helpen. Op het internet zal je eerst de versiebeheertools tegenkomen die voor open source projecten dienen, maar je kan perfect een eigen computer/NAS/server gebruiken om die code gezamenlijk op bij te houden, wat dan ook nog eens handig werkt als back-up.

[ Voor 6% gewijzigd door Glodenox op 09-05-2015 14:11 ]

[pina]

bedankt voor de vele suggesties!

Het is hoofdzakelijk gewoon om te voorkomen dat verschillende mensen tegelijk aan bestanden werken. Al is versioning ook altijd handig maar niet noodzakelijk. De reden waarom ik er iets op tegen heb om het te uploaden, en ben er zeker van dat het ook gewoon niet mag van het bedrijf, is gewoon dat je dan in wezen extern plaatst. Bovendien zijn de websites te groot om alle bestanden op Git te uploaden.

Het jammere is nu wel dat het nogal een klus is om die Git te installeren, want wij zelf kunnen niet rechtstreeks zo'n zaken installeren op de server, dat gebeurt door de helpdesk van het bedrijf.

Ik vind het gewoon een beetje vreemd dat er dezer dagen geen eenvoudigere oplossingen voor zijn. Bij Word of Excel is dat zelfs al mogelijk, daar kunnen 2 gebruikers gewoon niet tegelijk een bestand bewerken. Zo'n basisfunctionaliteit vind ik dan op zich wel een beetje overkill dat we zoveel moeite moeten doen om het gedaan te krijgen

[pina]

Ramon schreef op zaterdag 09 mei 2015 @ 10:53:
Ik snap verder niet helemaal hoe de statische websites draaien. Draaien deze enkel op jullie gedeelde (lokale) server en komen ze niet terecht op een server die aan het internet hangt? In zo'n geval moet je de website dus ontwikkelen op jullie eigen lokale machine en daarna kan je je wijzigingen committen en pushen en dan naar de server toe gaan en een 'git pull' uitvoeren. Er zijn ook allerlei tools beschikbaar om dit te automatiseren.

de sites staan op een lokale server bij ons. Wanneer iemand een aanpassing moet doen, opent die de bestanden rechtstreeks van de lokale server. Als alles klaar is, verplaatst hij de aangepaste bestanden naar de test-server (ook via de finder, niet via ftp of zo). Dan kunnen zij dat publishen via een andere tool als alles live mag gaan. Dus eigenlijk wordt er lokaal niets gedaan of bijgehouden.

[Glodenox]

Het als gedeeld markeren van Office-bestanden is een functionaliteit die eigen is aan Office. Maar als er iemand met een ander programma zonder die functionaliteit aanpassingen gaat maken aan diezelfde documenten ga je nog altijd dezelfde problemen hebben als vroeger Op algemeen bestandsniveau bestaat er jammer genoeg zo geen functionaliteit. Je kan wel bestanden als alleen-lezen zetten als je hier aanpassingen gaat aan maken, maar dat lijkt me maar een halfslachtige oplossing.

Dat niet alles in een versiebeheersysteem gezet kan worden is trouwens onzin. Er zijn echter wel zaken die je best niet in het systeem zet omdat deze nooit veranderen, enkel informatie bevatten die lokaal nuttig zijn (zoals je persoonlijke projectinstellingen als je tool deze daar opslaat) of zaken die tijdens het builden van de applicatie gegenereerd worden. Maar zelfs de allergrootste websites zullen 100% zeker gebruik maken van een versiebeheerssysteem. Je moet al echt zeer simpele sites maken vooraleer je er geen voordeel uit zou halen.

Nota: op het moment dat je bij versiebeheer een bestand commit dat ondertussen al door iemand anders aangepast is ga je de bestanden moeten "mergen". Dit kan soms zeer vlot (als de wijzigingen op een helemaal ander deel van de code inwerken) of soms heel moeilijk (als jullie beiden dezelfde delen van de code aangepast hebben).

Dus echt voorkomen dat twee gebruikers aan hetzelfde bestand beginnen te werken is niet mogelijk zonder je van speciale tools gebruik gaat maken of je onderling zeer goed afspreekt wie wat mag aanpassen (maar dat zal sowieso redelijk vaak nog fout gaan, met alle gevolgen van dien).

[Ramon]

pina schreef op zaterdag 09 mei 2015 @ 16:30:
[...]

No offense maar je praat als iemand die nog nooit versiebeheer heeft gebruikt

Je denkt bijvoorbeeld dat je doel is om te voorkomen dat meerdere mensen aan hetzelfde bestand werken. Denk daar eens serieus over na. Wat gebeurt er als ik een bestand open voor bewerking terwijl jij dat al had geopend? Dan mag ik met mijn duimen gaan draaien totdat jij klaar bent? Dat is niet praktisch....

Je doel is dus: Iedereen moet altijd zijn/haar werk kunnen doen zonder anderen dwars te zitten. Mocht het zo zijn dat ik in hetzelfde bestand iets heb aangepast als jij dan wil ik daar een melding van krijgen zodat ik bij twijfel jou erbij kan roepen om te kijken wat het gezamelijke resultaat van onze beide bewerkingen moet zijn.

Ik weet niet wat voor websites het zijn en wat voor extreem gevoelige data er statisch in staat, maar hele volksstammen gebruiken hosted git zoals bitbucket of github. Ook met gigabytes aan data gaat dat uitstekend. Júíst met grote sites heb je veel aan git, want hoe ga je anders garanderen dat het klopt wat er live staat?

Wat betreft Word, die maakt gewoon een lockfile aan. Als je helemaal moedeloos bent kan je natuurlijk een tool gaan schrijven die een lockfile aanmaakt voor ieder bestand wat jij geopend hebt, maar of je daar nou gelukkig van gaat worden

pina schreef op zaterdag 09 mei 2015 @ 16:37:
[...]


de sites staan op een lokale server bij ons. Wanneer iemand een aanpassing moet doen, opent die de bestanden rechtstreeks van de lokale server. Als alles klaar is, verplaatst hij de aangepaste bestanden naar de test-server (ook via de finder, niet via ftp of zo). Dan kunnen zij dat publishen via een andere tool als alles live mag gaan. Dus eigenlijk wordt er lokaal niets gedaan of bijgehouden.

Of je nou via de finder of via ftp doet, is allebei even fout.

Je snapt dat dit geen efficiënte workflow is.

De lokale server zou je moeten verplaatsen. Die komt op je eigen machine te staan. Dit kan omdat het statische sites zijn gewoon een simpele WAMP install zijn.

Je ontwikkelt en test dan dus lokaal op je eigen machine. Als je klaar bent met je werk commit en push je je wijzigingen. Op de test-server haal je de meest recente commit binnen (waarmee je dus automatisch werk van anderen meeneemt) en test je nogmaals of alles goed werkt en pas daarna deploy je naar live.

[ Voor 5% gewijzigd door Ramon op 09-05-2015 18:17 ]

[pina]

Ramon schreef op zaterdag 09 mei 2015 @ 17:32:
[...]

Wat gebeurt er als ik een bestand open voor bewerking terwijl jij dat al had geopend? Dan mag ik met mijn duimen gaan draaien totdat jij klaar bent? Dat is niet praktisch....

Je doel is dus: Iedereen moet altijd zijn/haar werk kunnen doen zonder anderen dwars te zitten. Mocht het zo zijn dat ik in hetzelfde bestand iets heb aangepast als jij dan wil ik daar een melding van krijgen zodat ik bij twijfel jou erbij kan roepen om te kijken wat het gezamelijke resultaat van onze beide bewerkingen moet zijn.

Ik weet niet wat voor websites het zijn en wat voor extreem gevoelige data er statisch in staat, maar hele volksstammen gebruiken hosted git zoals bitbucket of github. Ook met gigabytes aan data gaat dat uitstekend. Júíst met grote sites heb je veel aan git, want hoe ga je anders garanderen dat het klopt wat er live staat?


[...]
Of je nou via de finder of via ftp doet, is allebei even fout.

Je snapt dat dit geen efficiënte workflow is.

De lokale server zou je moeten verplaatsen. Die komt op je eigen machine te staan. Dit kan omdat het statische sites zijn gewoon een simpele WAMP install zijn.

Je ontwikkelt en test dan dus lokaal op je eigen machine. Als je klaar bent met je werk commit en push je je wijzigingen. Op de test-server haal je de meest recente commit binnen (waarmee je dus automatisch werk van anderen meeneemt) en test je nogmaals of alles goed werkt en pas daarna deploy je naar live.

eigenlijk is het idd wel zo op dit moment: niemand mag tegelijk aan een bvb index.htm werken... maar er is zodanig veel werk aan veel verschillende websites, dat niemand met zijn vingers zal draaien maar in se is het wel zo dat die andere persoon er dan niet in mag werken.

Bij mijn huidige werkgever en bij mijn vorige werkgevers, werken we niet meer lokaal, maar is lokaal verplaatst naar een jobs-server. Buiten dat het sneller werkt lokaal, vind ik het eigenlijk zelfs logisch dat alles op een gemeenschappelijke server staat ipv lokaal op een toestel. Als iemand dan iets nodig heeft omdat die persoon ziek is, dan staat het tenminste op een server waar iedereen bij kan. Want daarnaast heb je ook nog werkbestanden zoals PSD's en die zet je natuurlijk niet mee op de 'deploy-server' waar de websites op live gaan staan

[ Voor 3% gewijzigd door pina op 09-05-2015 19:55 ]

[Glodenox]

Nee, maar het is bijvoorbeeld wel nuttig om deze bestanden met versiebeheer bij te houden. Hoewel deze bestanden waarschijnlijk wel binaire files zijn waardoor je geen diff kan uitvoeren blijft het wel handig om bij fouten je wijzigingen terug te kunnen rollen, waar je vroeger gewoon geluk moest hebben om nog een oude versie te kunnen vinden in een of andere back-up.

Om te reageren op de werkbestanden zoals PSD's: je kan in zo'n systeem per project een folder hebben die dan nog eens een subfolder heeft voor werkbestanden en een andere subfolder voor wat er effectief op de server dient te staan. Waar ik werk genereren we artefacts (zeg maar zipbestanden en dergelijke) die de bestanden bevatten die we effectief gaan gebruiken.

Over het lokaal uitvoeren: wij ontwikkelen onze websites ook altijd met een lokale server. We hebben voor de database een sql-script om de lokale databank op te stellen en in te vullen of opnieuw te verversen. Dit script staat op onze SVN in het werkmapje en wordt uitgebreid samen met extra features die deze extra gegevens gebruiken. Maar we ontwikkelen eigenlijk zeer weinig websites, het zijn eerder SOAP web services bij ons met nauwelijks gebruik van databanken.

[Ramon]

pina schreef op zaterdag 09 mei 2015 @ 19:50:
[...]


eigenlijk is het idd wel zo op dit moment: niemand mag tegelijk aan een bvb index.htm werken... maar er is zodanig veel werk aan veel verschillende websites, dat niemand met zijn vingers zal draaien maar in se is het wel zo dat die andere persoon er dan niet in mag werken.

Bij mijn huidige werkgever en bij mijn vorige werkgevers, werken we niet meer lokaal, maar is lokaal verplaatst naar een jobs-server.

Ik heb ook bij zulke werkgevers gewerkt. Bazen en collega's die uit alle macht graag altijd alles hetzelfde wilden houden en het liefst via FTP hun websites live zetten. Daar heb ik het nooit langer dan een half jaar uitgehouden. Je moet je met zoveel shit bezig houden waar je geen last van hebt als je gewoon versiebeheer gebruikt.

Buiten dat het sneller werkt lokaal, vind ik het eigenlijk zelfs logisch dat alles op een gemeenschappelijke server staat ipv lokaal op een toestel.

Voordat je zulke smilies gaat gebruiken zou ik eerst zorgen dat je weet wat versiebeheer nu eigenlijk is.

Een paar artikelen:
http://thetomorrowlab.com...ould-use-version-control/
http://www.makeuseof.com/...-control-youre-developer/

Als iemand dan iets nodig heeft omdat die persoon ziek is, dan staat het tenminste op een server waar iedereen bij kan. Want daarnaast heb je ook nog werkbestanden zoals PSD's en die zet je natuurlijk niet mee op de 'deploy-server' waar de websites op live gaan staan

De lokale omgeving plus de git repository zijn samen eigenlijk de vervanger voor de "jobs server" en de git repository is dus de centrale opslag van je code. Waar dus iedereen bij kan. Door commits naar de git repository te 'pushen' en er nieuwe commits vandaan te 'pullen' kan je dan werken. Daarna kan je per regel zien wie wat gedaan heeft en waarom. Als iemand ziek is, is er dus geen probleem, want het staat centraal op die git repository.

De PSD's hou je uiteraard buiten de repository.

[Antique]

Als je systemen zoals Git teveel gedoe vindt, kun je ook eventueel nog een "collaborative text-editor" overwegen. Probeer op een vrijdagmiddag bijvoorbeeld eens of hier iets tussen zit voor je:
Wikipedia: Gobby
Wikipedia: MoonEdit

[Compizfox]

pina schreef op vrijdag 08 mei 2015 @ 19:40:
het andere is Git, maar dat werkt dan over het internet, dus moet je al die sites uploaden naar hun server, wat dan ook niet de bedoeling is.

Het is hoofdzakelijk gewoon om te voorkomen dat verschillende mensen tegelijk aan bestanden werken. Al is versioning ook altijd handig maar niet noodzakelijk. De reden waarom ik er iets op tegen heb om het te uploaden, en ben er zeker van dat het ook gewoon niet mag van het bedrijf, is gewoon dat je dan in wezen extern plaatst. Bovendien zijn de websites te groot om alle bestanden op Git te uploaden.

Volgens mij verwar je nu Git en Github. Git is het versiebeheersysteem (dat wat jij zoekt). Github is een hostingdienst voor vrije software (die Git gebruikt).

Als je Git gebruikt hoef je dus helemaal niets te uploaden naar een externe server. Je kunt gewoon lokaal werken (en je teamgenoot/collega ook) en dan van elkaar pullen.

Sterker nog, Git is juist ontwikkeld met een gedecentraliseerd systeem als belangrijkste feature. Je hebt dus helemaal geen centrale server nodig.

Het jammere is nu wel dat het nogal een klus is om die Git te installeren, want wij zelf kunnen niet rechtstreeks zo'n zaken installeren op de server, dat gebeurt door de helpdesk van het bedrijf.

Wat een onzin, Git installeren stelt niets voor. Je hoeft Git trouwens niet op de server te installeren, je installeert het alleen op de PCs waarop je aan het coden bent.

Ik vind het gewoon een beetje vreemd dat er dezer dagen geen eenvoudigere oplossingen voor zijn.

Volgens mij is Git de eenvoudigste oplossing. Het is in elk geval een stuk makkelijker dan CVS of SVN (heb ik me laten vertellen, geen persoonlijke ervaring daarmee)

Bij Word of Excel is dat zelfs al mogelijk, daar kunnen 2 gebruikers gewoon niet tegelijk een bestand bewerken. Zo'n basisfunctionaliteit vind ik dan op zich wel een beetje overkill dat we zoveel moeite moeten doen om het gedaan te krijgen

Ho wacht even, dus je wilt gewoon file locking? En hoe ga je het dan doen als je met z'n tweeën tegelijkertijd in één bestand iets moet aanpassen, ga je dan maar gewoon wachten tot de ander klaar is?

Dat nog even los van het feit dat Git (of een ander VCS) voor de wat serieuzere projecten eigenlijk noodzakelijk is, zelfs als je in je eentje werkt.

[ Voor 70% gewijzigd door Compizfox op 10-05-2015 00:36 ]

[pina]

heel interessant leesvoer

het is idd zo dat ik vooral bij conservatieve werkgevers heb gezeten. Bij deze is dat ook nog zo, maar is wel bereid om vooruit te gaan, vandaar dus mijn vraag hier. Ik ga eens de info doorspartelen die jullie mij hebben gegeven

[pina]

Compizfox schreef op zondag 10 mei 2015 @ 00:29:
Als je Git gebruikt hoef je dus helemaal niets te uploaden naar een externe server. Je kunt gewoon lokaal werken (en je teamgenoot/collega ook) en dan van elkaar pullen.

Sterker nog, Git is juist ontwikkeld met een gedecentraliseerd systeem als belangrijkste feature. Je hebt dus helemaal geen centrale server nodig.

Wat een onzin, Git installeren stelt niets voor. Je hoeft Git trouwens niet op de server te installeren, je installeert het alleen op de PCs waarop je aan het coden bent.

Als elke gebruiker dan Git apart kan installeren op zijn toestel, hoe kunnen zij dan werk van elkaar pullen? Het lijkt mij toch dat ze op een manier ergens een centrale server nodig hebben om toegang te hebben tot de bestanden?

Elke Git Gui die ik bekijk, vraag een remote account aan op bitbucket of github etc...

[Croga]

Het is mooi dat er allerlei tools zijn die dit soort dingen mogelijk maken maar met enorme bergen van jarenlange ervaring hebben een paar heel erg slimme mensen een paar jaar geleden het Agile Manifesto opgesteld. En de aller eerste regel uit dat manifesto luidt:
"Individuals and interactions over processes and tools"

Je hebt hier een probleem van samenwerking in een team. Dat probleem ga je niet oplossen met processen of tools, dat probleem moet je oplossen door met elkaar te praten!

Als het vaak voorkomt dat mensen aan hetzelfde bestand aan het werken zijn dan weet men blijkbaar niet wat de ander aan het doen is. Dat los je niet op door een proces of een tool, dat los je op door te zorgen dat je van elkaar weet wat je aan het doen bent. Wellicht is het slim om daar eens naar te kijken, gaat je een hoop "Damn, deze tool lost het nóg niet op" schelen.

[The Eagle]

^^^ Dat inderdaad. Zeker als je al niet zelf de controle over die server hebt, moet je dit procesmatig oplossen. Sowieso, edditen op een productiemachine

Wat je doet: productiemachine readonly, en 1 of twee personen aanwijzen die gecoordineerd zaken naar PRD migreren.
Verder laat je die "developers" lekker op een testomgeving hun ding doen. Komen ze er vanzelf wel achter als er iets niet klopt. En als twee mensen ineens aan jou het zelfde bestand van productie gaan vragen, weet je ook genoeg

[Ramon]

pina schreef op zondag 10 mei 2015 @ 12:19:
[...]


Als elke gebruiker dan Git apart kan installeren op zijn toestel, hoe kunnen zij dan werk van elkaar pullen? Het lijkt mij toch dat ze op een manier ergens een centrale server nodig hebben om toegang te hebben tot de bestanden?

Elke Git Gui die ik bekijk, vraag een remote account aan op bitbucket of github etc...

Zoals in de reactie die je quote staat kan je met git op een distributed manier werken, waar je commits naar elkaar kan sturen zonder via de centrale server te gaan.

Centrale workflow:



Decentrale workflow:


Bron: http://git-scm.com/book/e...Git-Distributed-Workflows

Maar dit is niet van belang in jouw geval. Ikzelf werk al 7 jaar met git en heb dit ook nog nooit gebruikt. Dit zou ik dus even vergeten Gewoon een centrale workflow aanhouden.

Croga schreef op zondag 10 mei 2015 @ 12:26:
Het is mooi dat er allerlei tools zijn die dit soort dingen mogelijk maken maar met enorme bergen van jarenlange ervaring hebben een paar heel erg slimme mensen een paar jaar geleden het Agile Manifesto opgesteld. En de aller eerste regel uit dat manifesto luidt:
"Individuals and interactions over processes and tools"

Je hebt hier een probleem van samenwerking in een team. Dat probleem ga je niet oplossen met processen of tools, dat probleem moet je oplossen door met elkaar te praten!

Als het vaak voorkomt dat mensen aan hetzelfde bestand aan het werken zijn dan weet men blijkbaar niet wat de ander aan het doen is. Dat los je niet op door een proces of een tool, dat los je op door te zorgen dat je van elkaar weet wat je aan het doen bent. Wellicht is het slim om daar eens naar te kijken, gaat je een hoop "Damn, deze tool lost het nóg niet op" schelen.

Ben ik niet met je eens. Je kan prima aan compleet andere features werken en toch in dezelfde html-bestanden bezig moeten zijn, in dezelfde (S)CSS bestanden of in dezelfde configuratie bestanden dingen hebben moeten toevoegen. Dat betekent echt niet dat je meteen een probleem hebt qua samenwerking.

Sterker nog een versiebeheer tool stelt je in staat om samen als organisatie te groeien omdat je exact inzicht hebt in wat een ander heeft gedaan zodat je daar over kan praten en er van kan leren.

The Eagle schreef op zondag 10 mei 2015 @ 12:49:
^^^ Dat inderdaad. Zeker als je al niet zelf de controle over die server hebt, moet je dit procesmatig oplossen. Sowieso, edditen op een productiemachine

Wat je doet: productiemachine readonly, en 1 of twee personen aanwijzen die gecoordineerd zaken naar PRD migreren.
Verder laat je die "developers" lekker op een testomgeving hun ding doen. Komen ze er vanzelf wel achter als er iets niet klopt. En als twee mensen ineens aan jou het zelfde bestand van productie gaan vragen, weet je ook genoeg

Dus eigenlijk zeg je, ga lekker zo door als nu en als er iets niet klopt (en iemand zijn paar uur werk is overschreven door iemand anders) merk je het vanzelf wel? Git is juist bedoeld om dat soort dingen te voorkomen.

[ Voor 3% gewijzigd door Ramon op 10-05-2015 13:14 ]

[pina]

decentrale manier van werken is idd niet echt efficiënt in mijn geval. De beste oplossing is nog altijd dus een git-server opzetten op de server waar de sites staan gehost, waarbij je dus de bestanden ook lokaal plaatst.
Maar zou het dan ook werken als je ipv lokaal werkt (op uw eigen mac), de bestanden op die job-server plaatst en dat als 'lokaal' beschouwt?

[Ramon]

pina schreef op zondag 10 mei 2015 @ 13:41:
decentrale manier van werken is idd niet echt efficiënt in mijn geval. De beste oplossing is nog altijd dus een git-server opzetten op de server waar de sites staan gehost, waarbij je dus de bestanden ook lokaal plaatst.
Maar zou het dan ook werken als je ipv lokaal werkt (op uw eigen mac), de bestanden op die job-server plaatst en dat als 'lokaal' beschouwt?

Als op die "job-server" iedere developer een eigen directory krijgt om zijn/haar werk in te doen dan kan dat ja.

Maar wat is daar het voordeel van? Wij hebben bij voorbeeld allemaal laptops en kunnen daardoor altijd en overal werken, ook bijvoorbeeld in de trein. Als je afhankelijk bent van een centrale job-server waar je bestanden op staan dan kan dat niet, of je moet moeilijk gaan doen met VPN-servers.

[pina]

bij ons mag er buiten de kantoren niet gewerkt worden
thuiswerk is nog uit den boze

nu ja, ik zal volgende week eens polsen welke opties we kunnen realiseren

[Rutix]

pina schreef op zondag 10 mei 2015 @ 22:24:
bij ons mag er buiten de kantoren niet gewerkt worden
thuiswerk is nog uit den boze

nu ja, ik zal volgende week eens polsen welke opties we kunnen realiseren

Prima dan maar dan nog steeds, waarom zou je niet gewoon lokaal aan je changes werken en die dan pushen naar de "remote" repository? Werkt veel sneller en dan krijg je ook geen clutter op je server. Daarnaast een simpele server voor Git stelt echt niks voor om te installeren. Wil je iets dat een web interface heeft zodat je pull requests ofzo kunt doen dan zou je altijd nog kunnen kijken naar https://about.gitlab.com/ . Super easy te installeren. Je kunt nu natuurlijk altijd simpel beginnen en dan later in de toekomst je workflow finetunen.

[pina]

Ik heb nog een vraag, wanneer bvb feedback terugkomt van de klant over bvb een mailing, is het soms moeilijk te beschrijven waar precies welke aanpassingen moeten gebeuren. Een pdf met annotaties is een mogelijkheid maat nogal omslachtig aangezien er feedback komt v verschillende personen.

Ik vraag mij dan af of er niet een platform bestaat waar wij bvb een screenshot uploaden waarop verschillende mensen dan notities en opmerkingen aan kunnen toevoegen met een pijltje of zo waar het moet gebeuren.

[Ramon]

pina schreef op woensdag 17 juni 2015 @ 00:30:
Ik heb nog een vraag, wanneer bvb feedback terugkomt van de klant over bvb een mailing, is het soms moeilijk te beschrijven waar precies welke aanpassingen moeten gebeuren. Een pdf met annotaties is een mogelijkheid maat nogal omslachtig aangezien er feedback komt v verschillende personen.

Ik vraag mij dan af of er niet een platform bestaat waar wij bvb een screenshot uploaden waarop verschillende mensen dan notities en opmerkingen aan kunnen toevoegen met een pijltje of zo waar het moet gebeuren.

Die zijn er bij de 100en ja. Heb je al gegoogled? Invision is een goede voor screenshots. Usabilla kan het op live websites.

[Cartman!]

Waarom niet gewoon met een ticket-systeem werken? GitHub en BitBucket bieden dit gewoon aan, dan zit alles (incl. je versiebeheer) op 1 plek. Wij gebruiken overigens Assemba hiervoor op kantoor.

[pina]

heb gegoogled, maar wist de juiste trefwoorden niet te vinden want weet niet echt hoe zoiets heet
dat zijn zaken die idd wel goed lijken, wel jammer op een manier dat het enkel met afbeeldingen werkt omdat wij ook vaak met mailings werken, waarbij de links daarin ook moeten getest worden.

maar ik kan ermee van start thnx!

[Ramon]

Usabilla heeft ook een variant voor mail.

[pina]

Hoi

Log bedrijf hier bij ons, de aangereikte oplossingen kunnen niet omdat niks extern mag geplaatst worden van projecten... Een beetje paranoia als je het mij vraagt.

Maar ik heb wel een alternatief gevonden in Chrome, waarbij je via een extension een screenshot kunt maken van uw pagina en er annotaties kan aan toevoegen. Dan kan je het bewaren als jpg. Probleem daarbij Is dan weer dat je tekst niet kan copy pasten uit die afbeelding....

Iemand die weet of er een extensie zou zijn die bovenstaande kan doen maar waarbij ik de tekst dan wel kan copy pasten? Denk dat het enkel kan als ze er een pdf van zouden maken

[danslo]

pina schreef op donderdag 16 juli 2015 @ 13:50:
Hoi

Log bedrijf hier bij ons, de aangereikte oplossingen kunnen niet omdat niks extern mag geplaatst worden van projecten... Een beetje paranoia als je het mij vraagt.

Dan zet je intern toch wat op? Bijvoorbeeld gitlab.