scm_versioning - Domenico Maria Giffone on Diigo

One reason is discipline, people not doing an update
and build before they commit. Another is environmental
differences between developers' machines
he basic rule of thumb is that you should be able
to walk up to the project with a virgin machine, do a
checkout, and be able to fully build the system.
26 more annotations...
- Keep your use of branches to a minimum. In particular
  have a mainline: a single branch of the project
  currently under development. Pretty much everyone should work
  off this mainline most of the time. (Reasonable branches are
  bug fixes of prior production releases and temporary experiments.)
- A common mistake is not to include everything in the
  automated build. The build should include getting the database schema
  out of the repository and firing it up in the execution
  environment. I'll elaborate my earlier rule of thumb:
  anyone should be able to bring in a virgin machine, check the sources
  out of the repository, issue a single command, and have a running
  system on their machine.
- t's okay for IDE users set up their own project files
  and use them for individual development. However it's essential to
  have a master build that is usable on a server and runnable from other
  scripts. So on a Java project we're okay with having developers build
  in their IDE, but the master build uses Ant to ensure it can be run on
  the development server.
- Both of these approaches make a point of writing tests before you
  write the code that makes them pass - in this mode the tests are as
  much about exploring the design of the system as they are about bug
  catching
- The result of running the test suite should indicate if
  any tests failed. For a build to be self-testing the failure of a test
  should cause the build to fail.
- As with any commit
  cycle the developer first updates their working copy to match
  the mainline, resolves any conflicts with the mainline, then
  builds on their local machine. If the build passes, then they
  are free to commit to the mainline.
- The key to fixing
  problems quickly is finding them quickly. With developers
  committing every few hours a conflict can be detected within a
  few hours of it occurring, at that point not much has
  happened and it's easy to resolve. Conflicts that stay
  undetected for weeks can be very hard to resolve.
- Try to speed up the commit build
- Introduce some automated testing into you build
- One of the first steps is to get the build automated
- As a result projects with Continuous Integration tend to have
  dramatically less bugs, both in production and in
  process. However I should stress that the degree of this benefit
  is directly tied to how good your test suite is
- you completely eliminate
  the blind spot. At all times you know where you are, what works,
  what doesn't, the outstanding bugs you have in your system.
- As a result you should ensure that regular builds happen on
  an integration machine and only if this integration build
  succeeds should the commit be considered to be done. Since the
  developer who commits is responsible for this, that developer
  needs to monitor the mainline build so they can fix it if it
  breaks. A corollary of this is that you shouldn't go home
  until the mainline build has passed with any commits you've
  added late in the day.
- Being able to
  automatically revert also reduces a lot of the tension of
  deployment, encouraging people to deploy more frequently and
  thus get new features out to users quickly
- If you deploy into production one extra automated
  capability you should consider is automated rollback.
- A natural consequence of this is that you should also have
  scripts that allow you to deploy into production with similar
  ease. You may not be deploying into production every day
  (although I've run into projects that do), but automatic
  deployment helps both speed up the process and reduce
  errors. It's also a cheap option since it just uses the same
  capabilities that you use to deploy into test environments.
- If you are following a process with well defined
  iterations, it's usually wise to also put the end of iteration
  builds there too
- To help make this work, anyone involved with a software
  project should be able to get the latest executable and be
  able to run it: for demonstrations, exploratory testing, or
  just to see what changed this week.
- Make it Easy for Anyone to Get the Latest Executable
- One of the most difficult parts of software development is
  making sure that you build the right software. We've found
  that it's very hard to specify what you want in advance and be
  correct; people find it much easier to see something that's
  not quite right and say how it needs to be changed. Agile
  development processes explicitly expect and take advantage of
  this part of human behavior.
- using virtualization to
  make it easy to put together test environments
- Test in a Clone of the Production Environment
- n this scenario people use the first stage as the commit build and use this
  as their main CI cycle
- A simple example of this is a two stage build
- Probably the most crucial step is to start working on
  setting up a staged build
- the greatest and most wide ranging
  benefit of Continuous Integration is reduced risk

Daily Builds Are Your Friend - Joel on Software

www.joelonsoftware.com/...fog0000000023.html - Preview

build continuous_integration devel scm_versioning

whoever broke the build became responsible for babysitting builds until somebody else broke it

Mergere Maestro

www.mergere.com/products_developers.jsp - Preview

continuous_integration devel java scm_versioning

Maestro:
A Simple Tool for

Complicated Builds

Domenico Maria Giffone's Library tagged scm_versioning → View Popular

subversion best practics

Subversion setup guide for Windows - Iceweasel

polishlinux.org » Manage Your Documents with Subversion - Iceweasel

svn4office.tigris.org - Iceweasel

svncontrol.tigris.org - Iceweasel

subview.tigris.org - Iceweasel

Subversion Cheat Sheet - Iceweasel

websvn.tigris.org - Iceweasel

Subversion User Guide - CleversafeWiki - Iceweasel

Gilbert's Blog : Weblog - Iceweasel

Building Java apps with Maven - Program - Java C C++ - Builder AU

Using maven-proxy to setup an internal maven repository - Sanjiv Jivan's Blog

Agile Development Envinronment

過労死 Death by Overcoding: Generating a Site and Documentation in Maven

java.net: Continuous Integration with Continuum

Automation for the people: Choosing a Continuous Integration server

http://www.javaworld.com/javaworld/jw-05-2006/jw-0529-maven.html

The Maven 2 POM demystified

The evolution of a project model

Continuous Integration

Daily Builds Are Your Friend - Joel on Software

Mergere Maestro

Selected Tags

Related Tags

Sponsored Links