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 build tool is Apache Continuum, but we should investigate Bamboo for its Jira integration
• every build should have a build number to identify it
• the official build system is isda-build1.mit.edu. No release build should be done on any individual developer's system.
• The build should be completely clean, everything needed should be checked out from svn from scratch.
• "Release" builds (builds going to Test or Production) are deployed from the official build machine to the target system(s)

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
• Builds should be deployed to a Test server for QA purposes, and should be labelled as QA builds. QA should not waste time on daily builds -- this is the work of developers to debug.

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, and may have an additional "Staging" environment as well. These may be virtual, they may be clustered or load-balanced, but they must be distinct.
• The Dev system is used for integration (every developer is assumed to have their own build & test environment locally), and is assumed to be running a daily build.
• The Test system is for QA purposes, and if validated, the build may then be deployed to Staging or Production.
• The Staging system is especially necessary for middleware projects, where other MIT developers need access to a system that is just as reliable as Production, but is not the Production data and cannot affect Production processes.
• Production is Production, and needs to live up to the SLAs defined for the particular projects.
• Patches may be made to Test, Staging, or Production servers.  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, and significant project tasks.

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