I am developing my report and I would like to trace what is the last version of the report deployed on the server.
I was thinking about checking last modification date of the report but still I have not idea how to do it in BIRT. Do you have any other ideas how to do that?
I do two things,
First:
Use naming convention. All reports in the same family start with the family identifier in this case CoM (Configuration Management, which is a module in the tool be reported on) followed by a descriptive name of the report.
CoM_ProductType.rptdesign
This is the name used for all production versions of the report. Drop it in to where ever you store production versions (copy and replace) and existing links continue to function.
Second
Use a version Naming convention and track your changes and updates in the description attribute of the report. This report has 3 version, Only the A3 version was promoted to production, the others were points during design and build. I also track the report request number (C0000538688) and other significant changes.
CoM_ProductType_A1.rptdesign
CoM_ProductType_A2.rptdesign
CoM_ProductType_A3.rptdesign
I save all the old version in an archive folder, that way when 2 weeks later the client decides they really did not want what they thought they wanted and start asking "can you change it back?" I just look through the notes in the description, go to the archive and pull up their last favorite version and redeploy it to production.
Related
I am not sure whether i can the problem good explaning. Well we use TFS for our building. And in our VS solution, there is also an installshield setup project.
Well, sometimes our team members forget the increase products' versions that why we want to give the version number automatically generated like 3.7.1.*
so when we build the project, the version of our product dll/exe will be 3.7.1.5655
and let say we've created the following versions
3.7.1.1234
3.7.1.5678
3.7.1.9134
and we gave the product Version 3.7.1.5678 to our customer. And after a while, the customer said that there is a bug in this version and the version number is 3.7.1.5678.
So, as I said earlier, we made the version number format like 3.7.1.* and we commit always like that so the assemblyinfo.cs file will not be changed. and when the customer said that the version 3.7.1.5678 has problem. how can we find the related version what the customer has, in tfs commit. Let say we committed several time in the same day and we cannot see (or i dont know it) where the version number 3.7.1.5678 has been stored.
Well, I need to find the realted commit and work on this time project but i dont cannot know which commit it was.
My question is that how you solve this problem?
I hope i could explain it.
We have TFS Version 16.122.26918.3 and we use mostly Visual Studio 2017
You could find the corresponding build of version number which is 3.7.1.5678.
For a particular build, it's easy to get related changeset/commit.
Then you could pull down that changeset/commit from TFS to your local workspace, and work on the bugs.
Not sure what your build number looks like, it's better to make a part of build number the same as the last version number(5678), like the usage of $(BuildID).
$(BuildID) is an internal immutable ID.
The AssemblyInfoPatcher build feature isn't working. Some files are patched and some are not.
Assembly file version was specified, but couldn't be patched in file D:\TeamCity\Agent\buildAgent\work\6afd998e316c631f\La\Di\Da\Properties\AssemblyInfo.cs. Is necessary attribute missing?
I thought it was because it was 1.0.* since one of the failed files had this format, and one of the successful ones had the default 1.0.0.0 format, so I changed the attribute to 1.0.0.0 across the entire solution and now none of them work.
I get either the error above or:
Assembly version attributes were not found in ...
The attribute is defined and at least two other people on the team have confirmed that they can also see it using their production eyes.
Happy to stump up the cash so I can smash my work keyboard.
Well, I managed to get it working but not.
I had a Configuration Parameter called AssemblyVersionStringWithCounter that I set from a PowerShell script. I was using this in the patcher feature.
I changed it to be composed of other parameters like
%MajorVersionNumber%.%MinorVersionNumber%.%BuildWeek%.%build.counter%
And now it mods the files but the params are not set, the version is incorrect. Seems the AssemblyInfoPatcher cannot use values set during the build steps.
Seems I've wasted about £800 of my client's money when I should have just PowerShelled it from the start. Code is King.
in our company we use tfs for source control of sql database version,when developers change the database they generate Equivalent script and put it in sql tfs project and checked in it with related workItem.after build we generate patch with this script for clients,but before pacth we need to some one decide on priority of checked in script,now i want to this decition become automatic and my question is how could specified priority in the moment of check in?
Sorry for my bad english,if you want more informationn to answer let me know.thanks.
Version handling of databases seems to be a never-ending problem. At a previous client, we gave the databases version properties, and then stored patch scripts in folders for each version, e.g. "Patches/2.0.10", "Patches/2.1.0". The patch scripts could then be executed in the same order as they were checked in (creation date).
Upon release, we ended up generating a complete patch script consisting of all those separate patches merged together (since the patches often affected the same data, they could be optimized) along with a new version number, allowing us to record what version any given databes instance had.
There have been concerns that automatically tagging builds with build systems (TeamCity/CruiseControl) will create so many tags that Perforce will be bogged down.
The only references I've managed to find have said "unless you have numbers, don't worry about it." I'd rather worry now before polluting a 100+G repository.
Does anyone have systems doing 1000+ builds a month that have seen anything like this?
You could consider using automatic labels, which simply contain a view (the parts of the depot you are identifying) and a revision number (usually a changelist). Automatic labels put very little metadata in the database.
If you use static labels, you should periodically archive old labels to keep the size of the database under control.
You can find more info on these subjects at the Perforce Knowledge Base.
My company participates in Windows Error Reporting via Winqual. We'd like to add some additional data to our crash reports, using WERRegisterMemoryBlock. Obviously we'd like to make sure this is working before we ship our next version. How can we test it?
Is there a way to locally preview precisely what is going to be sent? Does this realistically reproduce what we are going to be able to retrieve from Winqual?
Alternatively, can we generate a real report from a developer machine, then retrieve the report from Winqual? How would we distinguish this test case from the rest of our Winqual data?
[...] can we generate a real report from a
developer machine, then retrieve the
report from Winqual?
build a special test version of your application
upload a product mapping for this test version to WER
crash the test version on a machine with error reporting enabled
check Winqual, after a couple of days a report should show up
if the report does not come with CAB data already, enable additional data request (in Winqual)
crash the test version again on a machine with error reporting enabled
check Winqual, after a couple of days a report with CAB data should be waiting for you
download the CAB data and check if/that it contains what you need (you will need to use WinDbg to get the full picture, VS is not as thorough with minidumps as WinDbg)
How would we distinguish this test
case from the rest of our Winqual
data?
give the test version a special name and version (EXE name and *.rc)
just using a different "product name" and "product version" (=WER friendly names) is not enough to get an extra event ID / bucket, but an extra EXE name plus "Product Name" for the application mapping should do the trick
The best test would be to map a test only version of your product. You can verify that the expected information is present and then make sure you change the version and upload a new product mapping file before shipping