scm related

designing and building
p5

Figure 1.1: How to build a great product

1.3 Road Map
infrastructure, techniques, and process

infrastructure
source code management system
automated build system
keep track of the bug reports, feature requests, and other issues

Techniques
Process

Stop after each section to determine whether you’re using the idea. If
you aren’t, then read How Do I Get Started? If you are using the idea,
read Am I Doing This Right? or Warning Signs to make sure you’re on
the right track.

NUnit
NAnt

using the NUnit framework for writing developer tests
NAnt for repeatable compilation and deployment
CruiseControl.NET for continuous integration upon every check-in to our Subversion code repository

Chapter 2:Tools and Infrastructure

find email from Betty telling you about her code changes
source code management (SCM)
checking the weekly report from your team’s bug tracking software
part of your build process includes running an automated test suite.

sandbox development:
 1.There’s only one fundamental rule to keep in mind: isolate others from the effect of your work until you are ready.
 2.source code, database instances, web services
 3.On your own developer machine, you edit local copies of source code files, compile, build, and test in splendid isolation from your team-mates.If you need to use a database, a web server, or any other resource while developing, make sure that you’re the only one using it.
 4.how do customers get the finished product
  build machine: an unattended server,all of the latest source code.
    builds, and tests
    The result of this build is the product release.
 5.a shipping build creates a new branch or tag within the repository to mark a known,released set of code, or perhaps that the shipping build wraps the code in installers for various platforms

Manage Assets:
 1.all you need to keep track of are files
  every version
 2.source code management (SCM) === version control (VC) system
 3.source code,graphics, build scripts, XML droppings,documentation
Script Your Build
 1.Script builds on day one
 2.Any machine can be a build machine
Build Automatically
 1.before you can implement an automatic build, you must already have a manual build system
 2.Ideally, you will rebuild every time the code changes.
  Continuous Integration.
 3.A CI tool sits on the build machine and rebuilds your project every time someone commits code.
  It also runs your test suites to catch functional errors
 4.You can also move beyond “Does it compile?” and ask “Does it run?”
 5.Every CI system lets you publish your results to HTML
 6.Most also let you send email
  Send Code Change Notifications
Track Issues
 1.issue list
  What version of the product has the issue
  Which customer
  How severe
  customer’s environment
  In what version of your product did the issue first occur?
  In what version of your product was it fixed
  Who fixed
  Who verified the fix?
 2.known-issues lists
Track Features
 1.A new feature in your product refers to added functionality
 2.Distinct feature and issue
  generate to-do lists
  who requested a feature is also crucial to prioritization
 Many products hit the 90 percent done mark and never get finished
 you should never work on anything that isn’t on a list with an assigned priority
Use a Testing Harness
 1.testing harness is used to create and testing harness run your tests.
 2.Be sure it has a command-line interface
 3.It should also be able to handle a unit test, a product test, or an integration test.
  Unit tests are designed to test your individual class or object
  Functional tests are written to test your entire product’s proper operation
  Performance tests measure how fast your product can run
  Load tests simulate how your product would perform with a large load on it
  Smoke tests are lightweight tests and must be carefully written to exercise key portions of your produc
   冒烟测试就是在每日build建立后，对系统的基本功能进行简单的测试。这种测试强调功能的覆盖率，而不对功能的正确性进行验证。
  Mock client testing is used to create tests from your client’s point of view
   Mock Object imitates a server or application resource.
  Integration tests look at how the various pieces of your product lines Integration tests work together
On Choosing Tools
 1.Use the best tool for the job
 2.Use open formats to integrate tools
When Not to Experiment
 1.Never have a vital part of your product cycle written in a niche or noncore technology especially if only one developer knows it
 2.Keep critical path technologies familiar
CruiseControl
MetaCheck
Bug Regression
Defect-Driven Testing
 

Chapter 3 Pragmatic Project Techniques
==improving collaboration
 You’ll become more aware of your project’s status, as well as your team members’ progress by using these ideas. 
 
The List,The tech lead,Daily meetings,Code reviews,Code change notifications

Work from The List
 1.The List is how you set your daily and weekly agendas
A Tech Leads
 1.Your tech lead both oversees and carries the technical responsibility for your software project
 2.Having a separate tech lead is ideal when your manager lacks the required technical expertise or when your teams are working on multiple projects.
 3.Why You Need a Tech Lead
  manager who didn’t understand the technology you were using
  unrealistic deadlines
  interface between the development team and management
Coordinate and Communicate Every Day
 1.Daily meetings are brief team encounters that encourage interaction and communication without putting a huge dent in your schedule.
 2.Each team member briefly shares what they are working on and what problems they’ve run into
 3.A good rule of thumb is to spend no more than one to two minutes per person
Review All Code
 Small, frequent code reviews keep your code clean, simple, and tidy
Send Code Change Notifications
 
============================================================
The List:
– Publicly available
– Prioritized
– On an estimated time line
– Living
Tech lead:
– Manages projects’ feature lists
– Tracks developers’ current tasks and status
– Helps assign priorities to each feature
– Insulates the team from external distractions
Daily meetings:
– Keep them short
– Require specifics
– List problems, but don’t solve them
Code reviews:
– Small amount of code reviewed
– One or two reviewers
– Happen frequently
– Don’t publish code without a review
Code change notifications:
– Email and publish notifications
– List the reviewer’s name
– List purpose of the code change or addition
– Include the diff or file itself, size permitting
===============================================================