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
- Example:
- 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.
- For core tables, use ModelEvents instead of IModelFactory
- Processes
- Transaction management
- Be careful of long-running, uncommited transactions. Unless you have strong rollback requirements, incremental commits are preferred to minimize overhead.
- Transaction management
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.