Development and Deployment Best Practices

The purpose of this page is to collect all current development and deployment best practices in a single place.

Table Creation

  • Boolean columns
    • Mandatory = Y (most always be mandatory with a default value)

Plugin Development

  • plugin naming convention
    • definition: url.topic.type.qualifier
    • It is ok to use short names (bp vs businesspartner) - just be consistent
    • examples
      • com.chuboe.order.event.setpaymentrule
      • com.chuboe.bp.event.createloc
      • com.logilite.bp.callout.setdefaults
      • com.yourco.bp.model.main
    • Try not have have overlapping names where one is a subset of another
      • Example:
        • com.chuboe.bp.process
        • com.chuboe.bp.process.getorders
      • If you find yourself in this situation use the .main suffix.
        • com.yourco.bp.model.main
  • Model Events vs IModelFactory
    • For core tables, use ModelEvents instead of IModelFactory
      • You should have a very compelling reason to create a IModelFactory for a core table.
    • For custom tables, get in the habit of always creating models for your tables.
  • Processes
    • Transaction management
      • Be careful of long-running, uncommited transactions. Unless you have strong rollback requirements, incremental commits are preferred to minimize overhead.

Quote Management

Quote management is import for many reasons.

  • Helps protect the budget
  • Ensure time is spent on most important activities
  • Give the project manager ability say no if too costly or complicated

It is understood that DEV will take some paid time to evaluate and formulate a quote. Generally (95% of the time),

  • It is assumed DEV will consume between 1 or 2 billable hours and respond accordingly.
  • If DEV is not able to find a quick solution, please respond with how much time you believe would be required to estimate.
  • 4 hours will be the absolute most DEV should consume without prior approval.
  • All DEV time entries should be prefixed with the ticket number (if there is no dedicated ticket number field in your time entry system.)

Ticket Management:

You can use any ticket system you wish. Here are some popular choices:

  • Google docs
    • Create a Google Doc whose name represents the next ticket number. Increment this number every time you create a new ticket.
    • Each new ticket you create will include the ticket number as the prefix.
    • The document/ticket will include your standard sections like: Summary, Details, Implementation, Acceptance Testing, etc...
    • As the development team creates release artifacts, they will create a date-stamped Release section at the bottom of the document to reference the location of the artifacts.
    • Chuck's Opinion
      • This system has worked for me for a very long time.
      • Google search is amazing.
  • Trello + Google Docs
    • Trello holds the ticket summary
    • Google Doc URL is referenced by trello ticket
    • Google Doc is option - only needed if ticket is sufficently complex as to outgrow trello's description.
    • Trello has a plugin that exposes a ticket number
    • Chuck's Opinion
      • Trello is overly simple
      • Trello + Google Docs provides a nice balance of using auto-generated tickets and summary from trello with the power of google docs.
    • Atlassian and github both have tools for managing tickets. Both are viable tools.
  • Below are common ticket statuses when using a kanban board.
    • TICKET DRAFT: Where we will flesh out a ticket prior to moving to YOU moving the card to QUOTE Dev for dev team to quote.
    • QUOTE DEV: You requesting a quote from DEV - Once quoted, DEV to move card to QUOTE REVIEW (DEV will not spend more than 2 hours generating a quote per email attached "Quoting Best Practices.pdf"
    • QUOTE REVIEW: DEV puts card here awaiting response from YOU, once approved, YOU moves the card to DEVELOPMENT APPROVED
    • URGENT TICKET: There are times when an urgent ticket will come that prevents the ability to quote due to time constraints. in these situations, please do not spend more than 4 hours on a ticket without requesting approval for additional time.
    • DEVELOPMENT APPROVED: If quote approved, YOU would move to this list. DEV will move the card to IN DEVELOPMENT once they begin work on the ticket.
    • IN DEVELOPMENT: Actively being worked on by DEV, once ready for testing DEV to move the card to READY FOR TEST DEPLOYMENT.
    • READY FOR TEST DEPLOYMENT: Ready for CHUBOE to release into test. Following deployment to Test, CHUBOE should move ticket to UAT
    • UAT: In test; awaiting user testing by YOU. YOU to move the card to READY FOR PROD DEPLOYMENT after testing complete. DEV to attach JAR to Card.
    • READY FOR PROD DEPLOYMENT: Staged for deployment, awaiting next deployment run. DEV to move card to DONE once deployed.
    • DONE: Deployed/Ticket complete.
    • BACKLOG/PARKING LOT: On hold, etc. If YOU wants start one of these cards up again, YOU will move it to the appropriate List.