In clearcase UCM, how I can check how many and when check-in is performed against a Incident.
Say I create the Incident(CQ 872xx) in clearquest and assigned it to the developer so that check-in can be performed in particular stream. Now at the end of release, I want to see when and how many times CQ 872xx is used for check-in in clearcase.
If the name of the ClearQuest Incident is set as an UCM activity in ClearCase (as an article like "Setup ClearCase & ClearQuest Connectors in a ClearQuest-Enabled UCM Environment" illustrates), then it is only a matter of listing the versions stored in that activity.
Each version checked-in against that UCM activity represents an instance when the developer has used that incident.
cleartool descr -l activity:CQ_872xx#\pvob
Related
I am managing releases for a team of 8 developers. We have three environments:
DEV - where we all make our changes
UAT - an environment for users to test changes
LIVE - live environment
We use Visual Studio 2015 and TFS 2017.
Developers make changes to files and submit them for release to UAT by emailing a list (sometimes with a changeset number). Sometimes different users will make changes to the same files but not all changes should be released.
Once tested in UAT, the changes are released to Live however sometimes a file needs to move from UAT to Live that has earlier changes in it that are not approved for Live release yet.
Please could I ask users' advice as to what the best way for managing this process should be? Unintended changes keep getting released to UAT or Live when they should remain in DEV or UAT.
Any advice would be very welcome. Thanks
Usually this kind of "the best way" question is primarily opinion-based and hard to answer.
Many good questions generate some degree of opinion based on expert
experience, but answers to this question will tend to be almost
entirely based on opinions, rather than facts, references, or specific
expertise.
Developers make changes to files and submit them for release to UAT by emailing a list (sometimes with a changeset number).
For this scenario, instead of using E-Mail to send lists, perhaps you could use this extension
This extension is a build task you can use in build steps. This task generates a markdown release notes file based on a template passed into the tool. Here is an example of release notes output:
Release notes for build SampleSolution.Master
Build Number: 20160229.3 Build started: 29/02/16 15:47:58 Source
Branch: refs/heads/master
Associated work items
Task 60 [Assigned by: Bill ] Design WP8 client Associated change
sets/commits
ID bf9be94e61f71f87cb068353f58e860b982a2b4b Added a template ID
8c3f8f9817606e48f37f8e6d25b5a212230d7a86 Start of the project
The suggestion on the comment is a way that fits your needs and your circumstances. You could create three branches stands for your three environments. And for each branch you could use branch policy(GIT) which will protect your branches and avoid unintended changes merged to UAT and Live.
Since the TFS system or any other tool is hard to judge whether some files are approved or not to release yet. It' based on your team management, you could use permissions in TFS to limit users who have access to deployment or do the release. For example only PM and team leader could handle this. Combine with work items, charts , test management, reports and other functions in TFS.
Note Team Foundation Server is a product that not only provides source code management,build, release, but also reporting, requirements management, project management (for both agile software development and waterfall teams), lab management and testing capabilities. It covers the entire application lifecycle, and enables DevOps capabilities.
Suggest you first go through the Release Management in TFS and also take a look at how to configure your release pipelines for multiple environments deployments
We are currently running multiple branches within TFS 2013:
Development
Release
Trunk
etc.
Each branch has an automated test build. The purpose of these builds is to publish the latest code (and database changes) for each branch to our test server for manual testing. We maintain a separate IIS application for each branch so that different versions can be tested simultaneously.
Each branch has unique .csproj, .xml profile and web.config settings which control which application and database each branch deploys to, which works great.
However when we merge from one branch to another, auto-merge replaces these branch specific settings causing us to deploy our test builds to the wrong URL and database.
I am aware that auto-merge can be completely disabled in Visual Studio settings but is there a way we can continue to use auto-merge except for specific files?
Any suggestions welcome
This is a well known problem with any code promotion model. I would suggest that you move instead to a binary promotion model.
http://nakedalm.com/building-release-pipeline-release-management-visual-studio-2013/
With a binary promotion model you build the bits once with replaceable parameters and create or use a tool that orchestrates the release and feeds it with the correct variables for each environment.
http://nakedalm.com/create-release-management-pipeline-professional-developers/
I recently built out an end to end scenario using VSO. You can see in the post the passing of the values for each environment.
The software industry is moving towards continuous delivery and continuous integration. Neither of which is possible in a code promotion model.
You could disable auto conflict resolving during merge, but in this case you have to resolve these conflict manually (ignore)
Options -> Source Control -> Visual Studio Team Foundation Server
Attempt to automatically resolve conflicts when they are generated
or you could use tf.exe for merge:
tf.exe merge /discard CS
use a changeset which will be always discard from merge.
I currently have a CI environment setup using the following tools:
VCS - ClearCase (UCM enabled)
CI Server - Jenkins
Build Engine - MSBuild
Basically Jenkins is polling my UCM Project's Integration stream every 2 minutes and building via a msbuild script I wrote.
While in ClearCase it is not a best practice having a individual stream for each developer, good CI demands private builds to be run before commiting the code. Added to that, ideally i would have atomic commits, which ClearCase provides just on the form of Deliver to stream.
Currently we are working directly on integration stream, and sometimes our builds fail because Jenkins starts building before the developer finishes her check-ins.
My question is, how can I have a private work area (Sandbox) and atomic commits on ClearCase without creating a stream for each developer? Am I missing something?
Currently we are working directly on integration stream, and sometimes our builds fail because Jenkins starts building before the developer finishes her check-ins
You can write your build script in order to detect if a deliver is in progress.
A deliver is characterized by an activity named deliver.xxx: you can list its content and see if any version in it is in checkout. If yes, the deliver is in progress.
If the most recent deliver has only checked-in versions, you can safely start your build.
Or:
How can I have a private work area (Sandbox) and atomic commits on ClearCase without creating a stream for each developer
A private area for Jenkins to use would be a snapshot view on each developer stream.
As the name suggests, a snapshot view would take a snapshot of the code, but you need to define a criteria suggesting that Jenkins can build what the snapshot view has updated.
What I have seen used is a 'BUILD' shifting label (a label you re-apply on the newly updated code, and used by Jenkins in his snapshot view with a selection rule based on that label):
The developer move his/her label when he/she thinks the current code is ready to be build, and a Jenkins jobs update its snapshot view on the developer stream, based on the versions referenced by said shifting label 'BUILD'.
In order to achieve continuous integration , i thought of writing Clearcase triggers.
I came to know post operation trigger [after delivered to integration stream] will be useful for me.
I just seek an advice from my architect regarding implementation of trigger.
He told me not to use as triggers are troublesome in multisite environment.
Is this myth or true? Has any one faced problems which made their builds more annoying due to triggers?
Please suggest me is it safe to use triggers in multisite environment or not?
Your architect may have refered to this technote, which ponts out the fact that:
By design, trigger types must be created locally in each VOB.
Trigger types, unlike other metadata types (labels, attributes, branches, elements, hyperlink), cannot be created as global resources in an Administrative VOB because they cannot properly traverse hyperlinks; which is how the Administrative VOBs connect to their client VOBs.
You can try and copy a trigger:
The cptype (copy type) command creates a new type object that is a copy of an existing type object. The existing and new objects can be in the same VOB, or in different VOBs. The copy can have the same name as the original only if you are making the copy in a different VOB.
But:
The two objects, original and copy, do not retain any connection after you execute this command.
They are merely two objects with the same properties, and perhaps even the same name. If there are any changes made to the trigger, such as by using cleartool mktrtype -replace, then those changes must be made manually to each copy of the trigger, or you must perform the copy again using the -replace switch; see the cptype reference page for more information.
I would recommend using an external system to monitor, trigger and report on your continuous integration.
You can either:
simplify your ClearCase setup by using CCRC instead of the multi-site workflow.
In which case, the article "Continuous integration with IBM Rational ClearCase Remote Client" can help (you don't have to use CruiseControl: Jenkins or Hudson or TeamCity are equally good in this case)
more generally letting a CI tools (again: CruiseControl: Jenkins or Hudson or TeamCity) monitor a specific view which said CI tool updates regularely, detect any changes and trigger the build. See "Realizing continuous integration".
How do you answer the following questions from managers, testers and other people in your team:
In what build is bug #829 fixed? What tasks have been completed in our current test build?
So simply put, how do you achieve traceability of your requirements, tasks and bugs right from them being reported reporting through to deployment? What processes, tools and techniques are you using to achieve this?
We use TRAC with SVN in our Company and perform daily rolling builds to DEV / STAGING & STABLE environments with regular scheduled deployments (once a month... ish) to a PRODUCTION Environment.
When a bug is reported, it's entered into TRAC and given a Tickets number (e.g. #1001)
When the bug is fixed, the code is checked back into SVN with the ticket number(#1001) in the SVN Checkin notes.
The developer takes a note of the SVN Changeset number (e.g. [5000]) and opens the TRAC web ui. When closing the ticket, they put the changeset number in the notes of the ticket.
This way, the SVN checkin reference the ticket... and the ticket references the SVN Checkin.
Our daily builds are then performed against an SVN Changeset (e.g. todays build is everything up to changeset [5050]) and a note is made of this in our deployment notice.
Deployed On | Environment | Changeset
--------------+-------------------------+--------------------------
10-01-2008 | DEV | 5100
10-01-2008 | STAGING | 5080
10-01-2008 | STABLE | 5050
01-01-2008 | PRODUCTION | 5000
That way the testers when reviewing fixes for testing know by the changeset in the ticket comments if the build they're looking at includes the fix.
We use TFS in conjunction with JetBrains' TeamCity for CI.
When associating check-ins with tasks, our custom check-in policy prepends the associated tasks and bugs with their ID's and titles to the check-in comments.
These comments are then used to generate the release notes, which are automatically generated for each build.
We are tagging the source control check-in with the defect number that has been fixed or the enhancement number that has been implemented.
By retrieving the check-in log between two builds, you can determine what has been implemented or fixed.
We use a managed SVN service called Beanstalk (http://www.beanstalkapp.com/) that allows you to easily tie in with a number of Bug/Feature management systems. In our case, we use Fog Creek's FogBugz for that end of things. SVN/Beanstalk permits you to make notes when you check in a build that will, in turn, affect the status of one or more FogBugz cases.
On the client end, we use Tortoise SVN and Visual SVN to manage the interaction of the local client and the Beanstalk SVN server (Tortoise provides the actual service, Visual SVN provides the integration between Tortoise SVN and MS Visual Studio).
I highly recommend both services and the Tortoise/Visual SVN client.
We are using Fogbugz which has build-in subversion integration. Basically there is a plugin for Fogbugz which checks for SVN check-ins in the background. So if you supply a Fogbugz-case id at your check-in, it gets automatically linked with this check-in.
As far as I know you don't need any special application (like Beanstalk for example).
The other way round is little tricky. In our company there is a convention that for every (future or past) build there is a "release" in Fogbugz. If you fix a bug or implement a feature you assign the case to the right release.
Then it's quite easy to get a list of all implemented features of build X.