TFS

I've been re-watching many of the sessions I watched while at Tech-Ed 2008 in Barcelona. I've also been watching some of the sessions that I hadn't been able to attend. One of them being how Team Foundation Server is being used at Microsoft. A couple of things gets under my skin in terms of why can they do it and I can't.

Thousands of users, terabytes of data. OMG! If its good enough for them surely its good enough for us! Is it overkill for a small software development team? Is there a substantial cost of ownership? According to the session it can support Agile methodologies niucely. Generally i got a lot of agile vibes from Tech-Ed. Now if thats a marketing strategy or if its for real who knows. But they have me convinced. Anyway, I think i'd like giving it another twirl some time. There's just no time is there...

XP

I've finally got my hands on Extreme Programming Explained: Embrace Change (2nd Edition) . I'm about half was through so far, but I must admit I was hoping for more detail on some of the practices. I've generally found that http://www.extremeprogramming.org/ had a very good amount of information about XP, and presented in a very nice manner. I was hoping the book would expand on this. I do wonder if the first edition of the book has the extra info I would like, but I don't think I'm going to get it.

My next buy will probably be the SCRUM book. I've heard good stuff about SCRUM, and watched a few sessions at Tech-Ed on it. I think it'll do our organisation good.

Release Processes

At various points in the software development lifecycle it is deemed necessary to release a version of software. This may be for testing within the organization or outside of it (internal release or external release), or because the software is ready (final release). Large intervals between releases will result in less time used up for releases and more time for development. The release process should be as automated as possible to reduce this lost time. Smaller intervals between releases will result in better communication and feedback between developers and the release stakeholders. A balance between these two should be reached and an appropriate release interval should be agreed on for any given project. This document presents a set of requirements that must be met by a release and describes a release process that is intended to meet the requirements in conjunction with a versioning policy and a CM tool.

Release Requirements

Following is a list of requirements that must be met by each release.

1. Each release must be uniquely and easily identifiable with respect to older and future releases.
2. All sources (including code, resources, external libraries, etc) that go into a release are safely marked and stored, and the release can be reproduced from them. This is so that both a) when bugs arise, they may be investigated and solved with respect o the code that the bug was discovered in and b) releases may be made based on old versions of the software.
3. The release that (or at the least, the source of) a released artefact can be easily identified. This is so that both mismatches that may accidental occur on a target system may be identified and to enable the correct version of software to be examined and debugged when investigating a bug.
4. The changes that have been made since the last release can be identified. This is to help testers identify the areas of the system where testing should have a higher priority.
5. Future releases can be made based on old release with minor changes only.

In order to achieve these requirements the following needs emerge.

1. A Software Configuration Management (or Source Control) tool and usage guidelines to manage changing source code.
2. A Versioning Policy for the software produced.
3. A process for releasing software that relates the CM tool, the versioning policy and the steps needed to perform a build so that the release may meet the above requirements.

Release Process

The following diagram shows a release process aimed at meeting the previous requirements in conjunction with a CM tool and versioning policy. Each step in the process is described next.
Following are descriptions of each of the stages in the release process.

Retrieve Build Source

All the files that are needed in order to perform a build must be retried to insure that they are all up to date.

Build Code

Build all code that needs building. If the code can’t be build, the release process cannot continue. If the release is intended for eventual use outside the organization, then it can be build without debug information (release build) and with optimizations enabled. If the release is intended for testing within the organization, then it may be build with debug information to assist debugging and testing.

Compile Release Notes

Use comments from the CM tool to build a set of release notes that describe what has changed since the last release. These notes are intended for use buy testers to identify what areas of the software must have higher priority in terms of testing than others. These notes may also eventually be used to inform clients of changes made since the last version they have.

Move compiled artefacts to setup source folder

It is assumed that the setup project for takes its source folder (or folders). The compiled output must be moved into the source folder for the setup project.

Configure

Any configuration in terms of tracing etc must be performed here. For example , if the release if intended for eventual use outside the organization, then tracing must be removed or lowered so that it does not cause problems with disk usage etc on client machines.

Obfuscate

If the release is intended for eventual use outside the operation it should be obfuscated to prevent it being disassembled.

Build Setup

The setup project must be built. The output of this build will eventually be released.

Mark/ Tag/ Backup Source

Mark, tag, or backup (according to CM tool) the source that was used to produce the build.

Increase Versions

Increase versions of artifacts and the setup project in accordance with the versioning policy being used.

Commit New Versions

Commit new versions to the CM tool to prevent any future versions having the same version number as the one that will be released.

Release

Release the build setup by placing it in a known location with its version clearly visible and inform all the relevant people of the new release location.

Issue Tracking

Issue tracking systems can help to:
• Better facilitate communication between people working on a project.
• Provide a history of issues which have been encountered in a project and their progression and resolution in order to better support the system.
• Support a shorter product release cycle and manage interaction between development and testing (or generally Quality Assurance)
• Provide a snapshot into the issues being worked on in order to identify bottlenecks in the project.

I've been looking into issue tracking systems lately, BugZilla being the most bell known. I've looked at commercial ones like Jira and Gemini. I also read this very interesting article. All and all I've concluded on a simple tracking system called BugTracker.NET. It doesn't do half as much as most systems out there, but it does what i want it to do in the simplest way possible. Remember: Simple is your friend (as a wise senior software engineer in my old company used to tell me). The most important thing in the whole issue tracking ordeal I've decided is not the software you use, but the workflow, the roles of the users and the responsibilities they each have with respect to the issues. To that end, I've written up the following to describe these.

Primarily the attributes that are associated with issues are described. Next the workflow of an issue is presented with a description of each status the issue can be in. A description of the roles of users of the system is then presented and finally the responsibilities of each role with respect to what state an issue is in and the attributes is presented.

Issue Attributes

Issues are expected to have the following attributes for the purpose of capturing its state and history.

Project

This is the project that the issue relates to. Different people will have different roles with respect to issues of different projects.

Status

The status of an issue relates to where it is and who is responsible for it. The statuses of an issue are describes in the “Issue Workflow” section.

Category

The category of an issue reflects the work that must be performed on it. Examples of category values are bug, enhancement, new feature, client issue, documentation. It is possible to change the category of an issue as more information is found out about it, but appropriate comments must be added at each change.

Assigned To

This is the person that is in charge of dealing with the issue.

Priority

Priority is an indication to the person that is assigned to the issue regarding how he must tread the issue with respect to other issues assigned to them.

Resolution

This is the resolution given to an issue by the person in charge of the issue. Not all resolutions apply to all categories of issues. For example a bug may be fixed, unreproducible or not fixed. A client issue will be resolved and documentation will be drafted, reviewed or completed.

Comments

This is possible the most important attribute of the issue. It must contain all the information about the issue added by the various people that have been assigned to the issue. It must contain fault reproduction techniques as well as verification techniques for the issue if it is a bug, logs and other information such as resolution details if it relate to a client issue and more.

Issue Workflow

The diagram bellow shows the states that an issue within the issue tracking system takes.

New

When an issue is entered into the system, the default state is ‘New’. From this state an issue can go to either support, if it relates to a problem a client is having or to development if it is a bug.

Support

When an issue is taken by support, then support staff will be in contact with a client collection information about an issue and resolving the issue when the can. If they manage to resolve an issue it is passed to Quality Assurance to verify that the resolution is satisfactory and in line with the project quality plan. If the issue cannot be resolved by support it is passed to development with all the information that has been collected.

Development

When an issue is taken by development, then a developer will be put in charge of examining it and verifying if it is a bug and if so fixing it. If the developer needs more information in order to deal with the issue, they must add what they want in the comments and pass the issue back to support. Once a developer has fixed an issue then they move it over to Quality Assurance to verify that the issue had been dealt with (often this will be a case of testing).

Quality Assurance

When an issue is taken by quality assurance, then a QA staff member will be in charge of verifying that the issue has been satisfactorily resolved. This will often require that a bug fix be tested, but may also require documentation to verified or accessed. If the QA member is satisfied with the resolution, then they will move the issue to a closed state. If they are not satisfied they will move it to development or support depending on where it came from.

Closed

A closed issue is considered complete and is kept in the system for reference purposes and for helping future issues which may possible be similar to be resolved. In the event that after an issue is closed, it is discovered that the resolution was insufficient, then it is set to the reopened state with a comment on why it has been reopened.

Re Opened

An issue in the re opened state similar to an issue in the new state in that it must be assigned to either development of support for it to progress.

Roles

Users of the system can be grouped into the following groups or roles. A physical person may have more than one of the following roles in a given project and may have different roles in different projects. It is important for a user to know what their role is and what the responsibilities of these roles are.

Users

All users of the system may add issues to the system. When a new issue is added to the system the user has the following responsibilities:
1. Set the project of the issue
2. Set the Category of the issue if it is known
a. If the category is a bug, the user must add a reproduction procedure.
3. Set the status of the issue to ‘New’
4. Set a description of the issue
5. Set comments describing the issue
Users may also move an issue from closed to re-opened, in which case they must provide a comment describing why they have done so.

Development Managers

Development managers are in charge of the developers working on a project in that they are aware of the areas individual developers have worked on and have expertise in. Their responsibilities are
1. To check the tracking system for new or reopened issues that relate to development and move them to development.
2. Review all unassigned issues in development and assign an appropriate developer to work on each of them.
3. Set the priority of assigned issues where they have not been set
4. In cases where they can, they must add comments relating to how an issue must be resolved or where a developer must start looking in order to resolve an issue thus giving the developer a jump start in solving the issue.

Developers

Developers are in charge of the issues assigned to them. Developers must work on issues based on the priorities given to them.
When developers resolve an issue they must:
1. Set the resolution of the issue
2. Add a comment describing the resolution
3. If issue is a bug, they must
a. Add a verification method to the comments instructing QA how they should go about verifying the fix.
b. State the version in which the fix will be available
4. Un-assign themselves from the issue and
5. Move the issue to Quality Assurance.
When a developer needs more information from support they must:
1. Add a comment stating what is needed and how it may be obtained
2. Un-assign themselves from the issue and
3. Move the issue to Support

Support Managers

Support managers are in charge of support staff in that they know what each staff member has expertise in supporting. Their responsibilities are:
1. To check the tracking system for new or reopened issues that relates to support and move them to support.
2. Review all unassigned issues in support and assign an appropriate support staff member to work on each of them.
3. Set the priority of assigned issues where they have not been set
4. In cases where they can, they must add comments relating to how an issue must be resolved or how a support staff member must proceed in order to resolve an issue thus helping the support member.

Support Staff

Support staff members are in charge of issues assigned to them. They must work on issues based on the priorities given to them.
When a support staff, member resolves an issue they must:
1. Set the resolution of the issue
2. Add a comment describing the resolution
3. Un-assign themselves from the issue and
4. Move the issue to Quality Assurance.
When a support member cannot resolve an issue or has attained the information requested by development they must
1. Add a comment with all attained information regarding the issue
2. Add a fault reproduction technique if the issue is a bug.
3. Un-assign themselves from the issue and
4. Move the issue to Development

Quality Assurance Managers

Quality assurance managers are in charge of quality assurance staff in that they know what each staff member has expertise in supporting. Their responsibilities are:
1. Review all unassigned issues in quality assurance and assign an appropriate quality assurance staff member to work on each of them.

Quality Assurance Staff

Quality assurance staffs are in charge of issues assigned to them. They are responsible for verifying that the resolution of an issue is in line with the project quality plan. This may involve testing bug fixes, reviewing documents checking comments added to the issue as sufficient.
When an issue has been verified the quality assurance staff member must:
1. Add a comment describing the verification performed
2. Un-assign themselves from the issue.
3. Move the issue to closed state.
If the quality assurance staff member decides that the resolution does not meet quality standard (e.g. test fails, documentation is incomplete, Unit testing does not cover all the new code) they must
1. Add a comment describing why resolution does not meet quality standards
2. Un-assign themselves from the issue
3. Move the issue to support of development according to who put it up for quality assurance.

Oranizational Processes and Standards

I've tried to get the processes and standards i put together into a diagram to better visualize them and the relationships between them:


I've also written little overviews of each element:

Development Process

The development process is that that is used in order to stream line and organize the development effort from the start of a project till the end. Its goal is to help developers repeatedly produce quality software that meets user expectations. It will be made up of a number or other processes, practices and standards which may consist of traditional waterfall approach methods such as a sequence of analysis, requirements engineering, UML designs etc or it may use agile methods such as user stories, pair programming and continuous integration among others.

Coding Standards

Coding standards are qualities of code that must be adhered to by developers. They may include the following:
• What are, how and where to use Assertions
• What is, how and where to use Tracing
• Where to catch and throw Exceptions
• How much and what code should contain comments.
• How to deal with Compiler Warning
• Code metrics: what, how and why
• Globalizing code
• Naming conventions for variables, classes, operations etc.
Coding standard relate to Quality Management in that they define attributes of code that are believe to give it quality value.

Documentation

Documentation should be performed during the development process to give a high level explanation of what the software is meant to do and how it does it. Standards relating to what should be documented and how it should be documented must be defined and documentation should adhere to these. Documentation should be drafted, reviewed and published according to the organizations Document Management processes.

Document Management

Document management defines how documents should be created, reviewed, published, consumed and disposed. It usually included a document workflow and a system for storing and searching for documents.

Peer Review Process

Peer reviews are a quality control process that aim to informally check that code and document standards are being maintained. It involved a developer’s code and documentation being reviewed by a peer. This activity will also encourage better communication, team working and sharing of ideas and technical expertise between peers.

Work Logging

Work logging is the informal practice of developers logging the work they have done, issues they have encountered, solutions they have found and work they must do in order to help them deal with a faster pace of development, documentation and memory loss.

Configuration Management/ Source Control

These are two interrelated issues. Source Control involve being able to keep all code and resources that make up a project in a common location accessible to all developers. It enables many developers to work on the same source using either an optimistic or pessimistic strategy. Source control also involves keeping a history of all the changes made to source code in an efficient manner.
Configuration Management relates to the ability of identifying various versions of the software which has been released to customers and managing them with respect to future versions. Usually a source control tool is used to enable configuration management.

Unit Testing

Unit testing involves writing test fixtures side by side with code being developed. This way as code is changed, if a change breaks existing code it is detected immediately when tests are run. Unit testing aims at having a high code coverage meaning that when tests are run a high percentage of code has been executed. This is something that is very difficult to achieve with manual testing. Manual testing should be used on main use cases and to identify usability and business issues on a project level.

Continuous Integration

Continuous Integration (CI) aims at identifying issues caused when many developers working on the same project work with slightly different versions of the source code. When it comes to integrating, issues that are timely to fix usually occur. Continuous integration involves continuously integrating code, and immediately identifying such issues. A CI server is usually set up to monitor for changes in source code and given various triggers perform a build of the code. It will usually also run unit tests and inform the various stakeholders on the results.

Release Process

Identifying which version of code has gone in which release given for testing or to a client is important for both development and support. A release process is aimed at enabling this. Usually it involves giving the released software a version based on the versioning strategy and tagging a particular version of the code in the source control tool. The release process should be the process by which software is released for quality control via the Issue tracking system so that each issue in the issue tracking system can be pinned to a particular version of software.

Versioning Policy

Versioning software is not a trivial task. A policy must be decided where by the build, release, minor and major version of the software carry some form or meaning, and so that future releases can be made base on past versions. For example if version 1.0.0.0 is release to clients followed by version 1.0.0.1. Then if some clients require some of the new features in 1.0.0.1 but not all of them, then there is no version available to cover the fact that this new version is in between version 1.0.0.0 and version 1.0.0.1. The versioning policy must take this into account.

Issue/ Work Tracking Process

The issue tracking process is a particularly important one. It brings the whole of the organization together. It involves a workflow for issues that go through the various areas of the company (e.g. support, development and quality assurance).

Process Reviews

The various processes within the organization are there to assist developers in developing quality software and meeting business needs. They are not there to restrict them and stagger their creativity. As such each process should be reviewed and refined to the needs of the developers working within a project, during the course of the project and from project to project. This involves various reviews of the processes during the course of the projects and between them.

ToDo

After quite a while, and as a result of a heart to heart talk with our boss, I've been given the feeling that there will be an honest effort to develop some structure and define some development and quality standards and procedure within the company. He's asked me to make a first step in defining these in the form a documents and has promised to support and back them up.

To that extent I need to make a ToDo list of the areas I must document. Needless to say that these documents will be but a first draft, and will be subject to refactoring as they are used.

I'll changing the list ad adding / editing stuff with time to reflect my changing ideas and perceived requirements.

The List:

• Processes
• Configuration Management/SourceControl/Subversion Usage
• Continious Intergration (Goal of, Processes and Usage)/ Build Process
  
• Release Process
• Versioning Policy
  
• Issue Tracking Workflow (Must also select and set up a tool to support this) (See Issue Tracking & Bug Tracking)
• Document Management Process
• Deployment
• Pear Reviews
• Work Logging
• Process reviews (I've read Martin Fowlers The New Methodology Essay which talks about the motivation behind agile software development. He talks about the need for processes used in development to be self adaptive which I think is imperative to them being adopted,to them surviving the test of time with respect to their usefulness and to their improvement over time. He suggests this is possible via a process review process)
  
• Standards
• Documentation Standards (Architecture, Design & Implementation)
• Obfuscation
• Project Deliverables (e.g. Code, Unit Tests, Documentation)
• Coding Standards
  • Assertions
  • Tracing
  • Exceptions
  • Code Documentation
  • Warnings
  • Code Metrics
  • Globalization
  • Naming Conventions
    
  
  

Using Subversion

As far as source control is concerned I've decided to go for Subversion (SVN) using the TortoiseSVN client. I've been using this combination for a while now and through my experiences and articles I have read, I've come to believe it is one of the best source control systems out there despite it's freeness. I believe that commercial system offer more in terms of integrating source control with other systems such as the IDE, an issue tracking system, ect. etc., but no more in terms of a source control system. It's easy to use but behind the childlike interface of Tortoise is the power of a source control system that successes CVS which has been used in the majority of open source projects out there and as such is an indication of its ability to enable smooth collaboration between a development team. This is in my mind the primary goal of such a system.

The structure of the repository I'm going for is as follows:

• Trunk
  • Tools
  • Library
  • Source
    
• Tags
  • Builds
  • Releases
  • Other
    
• Branches
  • Tasks
  • Personal
  • Other

Each of these folders are described bellow:

Trunk

This is where all artefacts that are related to the project go.

Tools

Tools used in the build process of the project are stored here. Examples may include assembly merging tools (ILMerge), obfuscation tools, compilers, unit testing tools, etc.

Library

All externally compiled assemblies should be placed in an appropriate folder inside the library folder.
Additionally, svn-external projects/ libraries should be placed her. However, care should be taken with respect to Tags. If the SVN-Externs points to the head of a Trunk, then when Tagging, no information is stored with respect to which revision of the trunk was in use at the time. For this reason, when it becomes important for tags to be exact (for example for the purpose of recreating a build), svn-externs should be made to point to either a Tag or a specific revision. When this is the case, care should be taken to update this when changes are made to the external repository.

Source

All artefacts that are compiled or in some way make up the release should be placed here. Solution projects should be nested inside the solution folder. Each business project should ideally be made up of only one solution file. External assemblies/ Libraries/ Library projects should be referenced from the Library Folder. Setup projects should be in a folder of their own and the source files for the setup project should be taken from a source folder insider the setup project folder. Finally the source route should contain a batch file of something of that sort that generates a release. The hows and whys of this will be covered in a released post.
An example structure for the source folder is as follows:

• Source
  • Solution
    • projectA
    • projectB
  • SetupProject
    • SourceFiles
    • SupportFiles
  • build.bat

Tags

This is where Tags (snapshots of) the Trunk are kept to represent the state of the trunk at a particular moment of interest. Care should be taken not to commit changes made accidentally (and changes should not be made purposefully) to Tags. (Because SVN treats Tags and Branches in the same way, it allows this).

Builds

This is where tags of builds are kept. These are generally automatically created by the CI server.

Releases

This is where tags of releases (i.e. versions of the code that have been assigned a specific release version and have been sent for testing of to the client) are kept.

Other

This is where others tags are kept.

Branches

Branches are for copies of the trunk made in order to fulfil a particular task. Branches assist developers in that they allow them to commit unstable and untested code that should not under normal circumstances be committed to the trunk. It is often necessary to do this because a logical task may span over a few days in which case the developer will still want to keep his code in the safety of the repository.
The general purpose of branching is to eventually merge changes back into the trunk. In Subversion, this is often a delicate operation - not as straight forward as one would hope. So far I've found a couple of things that can cause issues when merging. These are generally related to renaming and moving files/ folder on the branch. (Maybe even on the trunk, though I haven't tried this). Thus my recommendation is to avoid these operations on branches.

Tasks

This folder contains branches that are related to a particular task (e.g. 'issue 345' or 'Adding paging to SearchLists'.

Personal

This folders contain branches that are for personal use/experimentation by developers

Other

This folder contains other branches.