AccuRev + Continuous Integration + Issue Tracking + Best/Current Practice As there are no current discussions, I thought I'd start one, with a topic I'm curious about.

1. Ben Weatherall（Configuration Manager at PDX, Inc.） David, Just so you don't go commentless... One of the "Best Practices" we follow is to have three types of builds: (1) Development, (2) CI and (3) Production or Release Candidate. (1) Development builds are those performed by developers for their own use. There are two thoughts on these builds: (A) They should use the same build infrastructure as the CM-controlled builds. These are often called Pre-flight builds. (B) They can use a developer-local build tool chain that may vary from the "official" CM-controlled one. As far as I can tell, there are only three good reasons to force developers to use option A. The first is that the developers cannot be trusted to use compatible tools and thus causing problems and delays when they transition their code to CM control. The second is the builds take too long on individual workstations or the external components (subsystems, libraries, etc.) are either too volatile or too large to use outside of a controlled environment. And finally, the build mechanism(s) available to developers is incompatible with the CM-controlled tool chain. We let the developers, through their Eclipse IDE, do their own local builds. (2) Continuous Integration, or CI, builds should just check the things that are REQUIRED to pass. This may be a simple compilation test or as complex as also running unit and smoke tests. The true purpose is to make sure early in the development cycle that the code that will be delivered to CM control will build properly in (3) while the build time itself is minimized. This allows early correction of build-related problems while the developer still has the changes they made firmly in mind. These builds should only be performed on code that has been Promoted, though some will attempt to do this after Keeps. The best way I have found to trigger these is with the server_post_promote trigger. Note that no snapshots are produced for these builds. We do compile and Unit Test execution in our CI builds. Things like static analysis and code coverage analysis should be performed by each developer as a part of their ongoing development process so there should be no surprises during the RC builds. (3) Production, Release Candidate, QA/QC, Controlled, etc. builds are those that generate packages ready for testing and/or deployment (release). Again, there are two ways these builds can be performed: (A) Instrumented for QA/QC testing and (B) Ready to be shipped. If the first option is used, the the second is also required. In both cases the builds should be done on the same codebase. The first time one of these builds is produced, either it should be performed against a snapshot or a time-based child stream and if the build is successful a snapshot produced from the parent stream (with the same time as the child's time-base). The purpose of option A is to allow regression and other testing that required non-production compilation, linking, etc. options. If this option is used it is also common to have Unit Test, Code Coverage and possibly automated regression testing also performed as a part of the build process. The hope is that all of this testing and analysis will allow for the early detection of problems that should never make it to production. The purpose of option B is to generate "stuff" that is ready to be "released" to production. If option A is also performed, this does not mean that additional testing is not required. Since the way the "deliverables" are generated is different, additional testing should be performed to make sure they still work as expected, otherwise the same additional tests should be performed here as well. Only option B can produce Release Candidates. From an AccuRev/AccuWork perspective, successful builds in this category will generate snapshots of the codebase used. They should also update some status information in AccuWork indicating at least which Change Packages were included. We do option B only. Hope this helps...

2. David Howland ( Sr Software Engineer at Xerox) Hi Ben, Great first post! From what I've read and seen this three step process of Developer, CI and Production build is rather typical. Developers create and run unit tests for their work. The CI builds the content and runs a (sub) set of unit and smoke tests and lastly the Production builds creates the "official" release. This is the final content that is then given to QA. As the CI and Production builds should have the same content when a Production build is created, I like to hear opinions on whether or not the CI build could be the Production build. Obviously the CI build would have to do all that the Production build does. An open question for all, what if any does your AccuRev stream structure impact your CI and Production builds? On to AccuWork Issues and CI. Do developers reuse the same issue for multiple promotes to the same baseline or do they use a new issue for each promote? If they use the same issue over again it is possible that an issue could be in release 1.0 and the same issue in 1.5. Again I'm interested in what others are doing/allowing in this regard. Dave -- AccuRev Evangelist

3. Steve Owens Software Engineer at Xerox

I think another thing that's rather typical is different levels of automated testing, as you alluded to. The developer would run the subset of tests that are affected by the changes made, the CI build would then run the full suite of unit tests, and the production build would run some form of functional test (ideally. I know this isn't particularly easy to do in certain circumstances). Tying promotion of the code to the passing of the tests should also be quite common. There is a problem with reusing the same AccuWork Issue repeatedly, but I can't remember what the specific AccuRev term for it was. It wasn't fatal: the code can still be promoted. The problem manifests itself when you do an issuelist, as some of the defects aren't listed because the content gets into a funky state. This makes it hard to automate the generation of defect lists for QA to validate. From a "best practices" perspective, I would add that you should find tools that integrate well together out of the box. There's nothing more frustrating in setting up a CI process than spending time writing glue code between the various pieces.

1. Ben Weatherall Configuration Manager at PDX, Inc.

   David: The AccuRev stream structure as such does not impact builds, either CI or RC. If your product builds are dependent on different projects (components, subsystems, etc.), then the relationship of the streams and the location of any interim objects (.lib, .ar, .dll, .jar, etc.) is affected by the stream structure. What is of more importance is how the workspaces used for building are set up by the build system. If the intent is to have incremental builds, then the content of the workspaces needs to be preserved between builds and they have to be specific to the stream and build type. The build scripts themselves also have to be created AND maintained so that intermediate files and directories are preserved, regardless of how many scripts there are in the "biuld set." If only clean builds are performed, then it is possible to have either transient workspaces, pooled workspaces or reference trees used for the builds. How this is managed is more a factor of your process coupled with the build system in use. As far as issue reuse, there are cases for "generic" issues (e.g. when the DBAs are updating DDL, seed data, etc. for a sprint or a release, or when the help system is being updated using generated components), but in general they should not be reused. We have found that if more than one person at a time is working on an issue that is easier if each has their own issue. This often calls for having a single "master" issue with each developer working on a unique "child" issue. Child issues can be closed independently, but the Master issue can be closed only when all children are closed first. We have also found that only changes from a single stream should be promoted against an issue. Whether or not you should perform merges using a special issue type (I forget exactly what AccuRev calls it, but we call it a merge issue) depends on which change package triggers you have running and what your desires are. Steve: When you do a Change Log, or whatever you call it, there are multiple ways of getting the data. If you look for transactions on the stream, don't forget to include the reverts and purges as well as the promotes. Also, if you stream inherits changes from a parent (dynamic streams), then there will not be a transaction for them and you will have to capture the changes using a diff or some other mechanism. AccuRev may know of another way to capture inherited changes in a Change Log, but I haven't found it yet. Writing glue code is sometimes necessary, but proper configurations and tailored processes often make it less necessary. I end up doing a lot of scripting just to satisfy the Process Committee.

2. Steve Owens Software Engineer at Xerox

   When the intention is to get a list of issues that are associated with the most recent promotions, then there is only one way to get the data: the issuelist command (unless you go directly to AccuWorks or whatever your defect tracking system is, but that has other potential issues, depending on your process). The current design of AccuRev does not display "incomplete" defects, and it is very easy to get a defect into that state if you reuse defect records arbitrarily. I'm just saying that there are potential pitfalls to reusing defects that people should be aware of before going down that path. You're right: writing glue code is sometimes necessary. However I believe that can be kept to a minimum. Part of that is understanding the requirements of the process before selecting the tools. The other part is modifying the process to accommodate what the available tools can do. It's a fine balancing act.