You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Source Code

  • Never change the formatting on someone else's source code file.
  • Include a header that has the appropriate license/copyright info
    • MIT license is fine, but think about this at the beginning of a project
  • Treat all projects as potentially open source

Source Control

  • Source control system of record is svn.mit.edu
  • everything needed for the build should be checked in -- dependent libraries, config files, etc.
  • a future goal is to have a read-only, web-browsable repository
  • a goal is Jira/SVN integration

Build Process

  • we use maven for Java builds, isda-maven1.mit.edu is our maven repository.
  • we do continuous build integration, in order to flush out problems quickly
  • our tool is Apache Continuum, but we should investigate Bamboo for its Jira integration
  • every build should have a build number to identify it

Testing and QA

  • Every project must have some kind of test plan
  • Before going into production, someone must sign off on the test plan to certify that the project is compliant with the quality criteria
  • There should be some kind of minimal smoke test to go with every build, as part of the continuous build integration
  • For Java, we use JMeter to do automated testing
  • We use YourKit for performance testing
  • We have been using Questcon as our outsourced QA partner

Release Engineering

  • SVN:
    • Every separately deployable piece of a project should have its own svn trunk, perhaps under a parent directory for the whole project
    • Every time a build is deployed to Test or Production, the trunk should be branched and given a release name/number
    • Test or Production patches should be made in the branch, then folded into the trunk
  • Every project has separate Dev, Test, and Production systems. These may be virtual, they may be clustered or load-balanced, but they must be distinct.
  • Patches made to production should have at least one reviewer who is not the implementor

Bug-tracking and Issue Management

  • Jira is the bug and issue tracking system.
  •  We are also using Jira to track feature requests, etc.

Customer Support 

  • We use RT for tracking customer issues & communications.
  • Every project must have a Service Level Agreement (or several, for different tiers)
  • Every project must have a support plan

Documentation

  • Every project should have a website, with a discussion forum for support, help docs, roadmap, etc. 

Project Management 

  • We are using e-project to communicate about projects across teams and directorates
  • We are using Jira to track bugs as well as features and "to-do" items
  • other project tools as required 

Project Infrastructure 

  •  
  • No labels