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.