Meet Tickety-Tick

: itʼs a design pattern which used to be super popular in the in 2016. I was in the audience back then and immediately sold on the idea 🥰.

Convention

At bitcrowd, branch names follow the format of <type>/<id>-<title> and the subject of the first commit message on that branch would be [#<id>] <title>:

• 
  

  type: the type of ticket

  
  
  

  This may be feature, bug, task, chore or whatever else the ticketing system uses.

  
  


• 
  

  id: the identifier of the ticket in the ticketing system

  
  
  

  This may be TT-5045 in , a UUID on , the for Chrome, Opera, Firefox or Safari. Then we need an ticket to work on. Tickety-Tick supports a constantly growing range of :

  
  
  
  
  

  The description is only pointing to a series of blog posts from the ESLint team explaining the new default configuration format. Letʼs assume we read it and are ready to start working on the ticket. So we open the Tickety-Tick browser extension either by clicking on the ticket icon in our browserʼs tool-bar or, if weʼre already among the power users, use the nifty ctrl t keyboard shortcut to open the extension popup:

  
  
  

  for more info about commit messages, subject vs. body, formatting, etc.

  
  
  
  

  With that, we can start coding away. Whether we decide to later of Tickety-Tick. It allows to adjust the naming patterns to the teamʼs needs, so that the tool can be used to enforce already existing conventions. The configuration options are powerful enough to cover any naming pattern your team may have come up with. Yet they are simple and limited enough to not have you spent hours on them.

  
  
  

  
  

  bitcrowd can help you to optimize your workflows and team organization! Just

  
  
  

  Having this fixed connection between ticket and source code and having all people in the team know about it, turned out to be extremely beneficial for pretty much every project or team weʼve seen so far. Itʼs an additional mean for knowledge sharing, makes onboarding newcomers on the codebase faster and is generally a trusted reference for any member of the team, newcomer to long term contributer. Itʼs an additional source of documentation for the code with a level of detail which would not be possible within the code itself.

  
  
  

  
  
  
  Further usage
  

  
  
  

  The encoded information about the connection between a ticket on the tracker and the code which later was written for it, can be used for further applications, like timetracking, work reports, etc.

  
  
  

  A whole new information heaven can be reached once on it!

  
  
  

  
  
  
  Try it!
  

  
  
  

  After all the praise, the only thing left to say is: Just yet, we can help you to put together a pull request for it. Weʼre always curious to find out which ticketing systems and workflows people use.

  
  
  

  If you have more questions about browser extensions or workflows, just hit us up!

  Vollständiger Original-Bericht

  Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

  ↗ Original-Artikel auf dev.to lesen