Page Comparison

Table of Contents
maxLevel 2 type flat

Recommended guidelines for Development workflow

• Create feature branches for new features using git flow
• Push code to remote branches early and often (ideally at least once a day)
• Have a clear and concise commit message
• Write unit tests to cover the functionality both positive and negative cases
• Build the code locally using maven without -DskipTests and check for any errors
• Check the builds on bamboo for your feature branch
  • Make sure you fix errors early 
• Ensure there are no checkstyle errors
  • mvn package -DskipTests will run checkstyle
• Create pull request to merge the code to develop branch
• Pull request description should contain the reason why the PR is created in a short summary
• Keep the pull requests small and focused 
• You can keep the same feature branch and keep sending pull requests as and when the feature is complete
  
  • Example: If you are working on implementing a metrics framework, the following steps would be logical points to send code reviews:
    • Java API  (without implementation)
    • REST API (without implementation)
    • Metrics processor implementation 
    • Java API implementation review
    • REST API implementation review
    • Kafka integration review
• Fix all code review comments
• Merge code after there is an approval in a pull request

...

$ git flow feature start <feature-name>
 
$ # Make your changes
 
$ git add <files>
 
$ git commit -m "Clear and concise commit messages"
 
$ git checkout develop
 
$ git pull 
 
$ git checkout feature/<branch>
 
$ git rebase develop 
 
$ git flow feature publish <feature-name>
 
$ git flow feature close <feature-name> 

Checklist before sending pull requests

•  Unit test builds for feature branches are successful in bamboo
•  No checkstyle errors in feature branch
•  Adequate unit tests are written for the feature

Continuous Delivery

The idea of Continuous Delivery (CD) is to keep the software always releasable so that we can release as often as possible whenever we wanted.

...

[From http://www.collab.net/sites/default/files/uploads/CollabNet-S-curve_2.png]

Development Best Practices

In this section, some best practices in design and development to ease CD are discussed.

Develop as libraries / components

Always try to break down the new feature you are working on into self-contain library / components so that abstraction boundary for integration can be defined properly (e.g. interfaces, class, REST endpoints, etc.)

Design for incremental changes

Break down task into multiple deliverables, each accompanied with appropriate unit tests and integration points to the rest of the system.

...

In this example, all changes made in step 1-4 are safe to merge and release, as no production code would be affected (new code are dead code to the release).

Feature toggle

In some cases, when the set of changes for the new feature is big and touched a lot of existing code, it is tempting to keep working on a branch not merging back to main trunk. However, this is not a good practice and defeated the purpose of CI. In order to be able to merge early, a technique called feature toggle could be used. Basically it uses configuration to turn on/off usage of new feature. The configuration may or may not be stayed after the feature is fully completed, depending on whether need to keep the old behavior or not.

Branch by Abstraction

Basically new abstractions are built (e.g. new interfaces) and have an implementation of the existing behavior. New features can then now be built by implementing the same interfaces, and potentially uses feature toggle to select what implementation to be used.

...