Vedtagelse af pro-arbejdsgange nu, hvor WordPress alt er vokset op

Jeg kan huske, at jeg opretter min første WordPress-blog. Jeg brugte timer på at følge guider online for at downloade WordPress, forsøger at uploade det igen og derefter finde ud af, hvordan man opretter en database.


Jeg bare FTP’ede hver ændring helt op til live-serveren og håbede, at bloggen ikke blev mørk, hvis jeg indtastede et spørgsmålstegn forkert.

WordPress er vokset op i mellemtiden. Massive mediefirmaer bruger WordPress som deres vigtigste måde at kommunikere med verden på. Gå til Tech Crunch eller New Yorker, og se kilden html. Du finder ud af, at webstedet er bygget ved hjælp af WordPress. Beyonce? Jep. Hun grave WordPress.

På samme tid har WordPress dette frygtelige ry blandt udviklere. Stereotypen er af script-kiddies, der uploader filer via FTP, bruger ikke versionskontrol og forlader generelt ethvert fornuftigt princip i softwareudvikling, der er kendt af menneskeheden.

Det er klart, det er ikke en retfærdig beskyldning. WordPress er vokset op. Det bliver en fuldgyldig REST API dette år. Du kan nu installere WordPress og afhængigheder fra kommandolinjen vha WP-CLI.

WordPress-udviklere og tema-designere vokser op. Roots.io er et eksempel på behandling af WordPress-projekter som ethvert seriøst softwareudviklingsprojekt. De roder ikke rundt med drag-n-drop FTP-upload. I stedet bruger de git til versionskontrol og capistrano til implementeringer.

Joel fra Fog Creek Software skrev berømt om 12 trin til bedre software, og en af ​​dem var et problem eller en bug tracker. Han har ret. Det er svært at huske alle de forskellige forskellige anmodninger om funktion og fejl i dit hoved. Det er endnu sværere at huske alle trin til gengivelse af fejl, hvad brugeren forventede og hvad de faktisk fik.

Der er kun så mange post-it-noter, du kan også på dit skrivebord. WordPress bruger selv Trac som dens tracker. Jeg har arbejdet med Redmine, et andet open source source-tracker og projektstyringsværktøj, fordi jeg er hos Planio, der tilbyder vært Redmine og git-hosting.

Den typiske brugstilfælde for en emnespor

Så forestil dig, at du bygger et nyt plugin til WordPress. Du har et lille team på jobbet – en udvikler eller to, en designer og en forretnings fyr.

Du er ikke længere et team med kun én person. I arbejder ikke alle ét sted, for fjernarbejde er godt, og den nordlige halvkugle er ikke så sjov om vinteren.

En bruger sender en e-mail, der siger, at plugin “ikke fungerer”. Hvis du virkelig er heldig, får du et skærmbillede, der viser en fejlmeddelelse om “fungerer ikke”.

Du videresender e-mailen rundt. Nogen e-mails tilbage med et spørgsmål om, hvilken browser de brugte, og pludselig har du en Gmail-tråd på 12 e-mails. Der er et par problemer indpakket her, og udleveringssporere hjælper dig med at løse disse problemer.

De tre kritiske stykker af hver ordentlig bug

Den første er, at du faktisk har brug for tre ting til hver fejlrapport:

  1. Hvilke trin tog brugeren, der resulterede i fejlen?
  2. Hvad forventede brugeren at se?
  3. Hvad så brugeren faktisk?

Du skal være i stand til at gengive fejlen, fordi det er virkelig svært at løse en fejl, som du ikke kan se i handling. For det andet skal du sørge for, at fejlen faktisk er en fejl, eller om brugeren forventede noget, som din software ikke leverer.

Her er en anden måde at sige det på:

Og du kan ikke narre den person, der rapporterer fejlen med den klassiske linje: “Det er ikke en fejl. Det er en funktion!”Hvis du ikke ved, hvad personen forventede i stedet.

Brug af en issue tracker som f.eks redmine betyder, at du har en standardiseret måde at modtage disse oplysninger på.

Der er en måde du kan sikre dig, at en opgave aldrig bliver udført: antydet vagt, at holdet skulle gøre noget ved det. Medmindre det er tildelt en “ejer”, bliver det bare ikke gjort.

Udstedelses trackere tvinger dig til at tildele et emne til, vel, en person på et givet tidspunkt, så du altid ved, hvem der i øjeblikket ejer en fejl eller en opgave. Samtidig gennemgår problemer en arbejdsgang med forskellige statuser som “I gang”, “QA / Testing” eller “Ready to Deployment”.

De fleste trackere giver dig rapporter baseret på den aktuelle status for et problem, så du kan se det aktuelle volumen af ​​det igangværende arbejde, og hvor meget der endnu skal gøres. Du kan endda oprette nedbrændingsdiagrammer, der er populariseret i smidige metoder.

Integrer Git tæt i din projektledelses arbejdsgang

Som vi nævnte ovenfor, vil brugen af ​​git i din WordPress-udviklingsproces gøre dit liv meget lettere, når ting går galt. Git giver dig en spole tilbage knappen på din kode, og du kan oprette flere, parallelle versioner af dit websted.

Hver gang du “begår” en ny kode til dit git-lager, opretter du et naturligt punkt for at diskutere ændringen af ​​kodebasen. Derudover synes jeg det er lettere at diskutere problemer baseret på faktiske engagerede kode snarere end bare vage ideer.

Det er her, emne trackers skinner, fordi Redmine for eksempel er tæt integreret med git eller svn. Du kan hurtigt se, hvem der har begået hvad imod spørgsmål, og derefter diskutere disse spørgsmål.

Opret et system til din WordPress-udvikling

En emnesporning hjælper dig med at skalere ud over bare dig selv. Du vil være sikker på, at problemer ikke glider gennem revnerne.

Hos Planio bruger størstedelen af ​​vores kunder vores hostede Redmine til at spore softwareudviklingsprojekter, herunder WordPress-projekter. De sporer bugs, nye funktioner og sprints i forbindelse med versionskontrol.

Redmine er ligesom WordPress open source, så du får fordelen ved ikke at være låst i proprietær software. Og ligesom WordPress kan du outsource hosting til en som os på Planio, eller du kan installere det selv, hvis du foretrækker det Redmine.org.

Over til dig

Så hvordan styrer du dine arbejdsgange? Har du prøvet Redmine? Vi vil meget gerne høre dine tanker og kommentarer nedenfor!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map