I have a product for which I build an MSI with VS setup solution.
Every time I want to deploy my changes the the customer I have to remote desktop to 4 machines, upload my new installer, uninstall the previous version and install the new version (run the MSI).
It's a bit tedious (particularly on 4 machines).
Is there a way I could automate the process (remote login / upload / uninstall / install) ins ome way (with PowerShell for example)?
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
My programs never have bugs, they just develop random features.
I'm hoping I have the correct forum here for a start.
I'm upgrading the Continuous Integration server and build process for our C# codebase.
The code is component based, with over 150 components, with lots of interdependencies.
We're currently building under CruiseControl, calling some NAnt scripts to build "everything" several times a day.
The NAnt scripts end up calling MSBuild on the solution files for each component.
I have written some NAnt tasks to iterate through the components parsing solution and CS project files to get output assemblies and their references, so that I can order the component builds based on dependencies. This code has also been 'reused' to produce a component catalog, which details the version of the assemblies/compoents used by each of our products. So this needs to be maintained.
I'm considering several CI servers for the upgrade:
UrbanBuild and OpenMake meister both claim to have dependency management handling for component based systems, but I need to actually talk to someone from each of these companies to get a price out of them.
TeamCity appears to have plugins/extensions for NAnt and AccuRev (I'm not really considering changing SCM if I can avoid it), but I haven't seen any mention of dependency management.
Team Foundation Server doesn't appear to support AccuRev or NAnt from what I can find, so I've kinda ruled it out at this stage.
If I do go for TeamCity, then I've had a brief look at NuGet and OpenWrap for dependency management, however OpenWrap appears to bypass msbuild, which probably rules out most of my NAnt scripts also, and they both appear to focus on 3rd Party dependency management.
So is anyone aware of a tool which will analyse inter-component dependencies in my code, and output some form of data that I could use to:
1. schedule the component builds from the bottom up, from the middle up or from the top down and
2. from which I could produce my component catalog and
3. could support plugin dependencies which don't use assembly references in the project files?
Does anyone know if either UrbanBuild or OpenMake Meister support this?
The sites for both of these products talk a good talk but don't flesh out the details to the extent I would like.
I've been googling this stuff on and off for a couple of weeks and I'm sure there has to be something out there that does what I'm looking for, but it doesn't seem to be making itself known to me.
I am sure this must have gone round before but, how many environments do you have / think is necessary?
We have quite a collection of inter-related systems here, in-house developed, off the shelf, heavily customised, and using a number of different languages and databases.
Some only exist in live, some have dev / test and live, most of our stuff has dev, test and live. The new daddy system that is yet to go live and needs to interface with most of the others has been setup with dev, test, train and live.
Just had the bloke in charge of this project come to see me quite panicky because he has realised that he doesn't know how to use these environments properly or what they are going to talk to with respect to the other systems. Training starts at the end of this month whilst I am on holiday .
I think it would be best if we had at least a nod at the same number of environments for each system as they all have to work together.
So, bearing in mind that all the systems we write or support are for our own group of companies, what environments would you recommend?
I think 3 is a minimum, I cannot decide if the 4th is necessary or not.
Previously I worked with dev, 8 test / train / whatever, and live. Which worked well, but then we only had the one system to support then. I have also worked with 5 environments, although I can't now remember what they all were, dev, test, qa, prod, I am sure there was one other.
Every man can tell how many goats or sheep he possesses, but not how many friends.
how many environments do you have / think is necessary?
As many as needed to solve the business needs of the company.
I think 3 is a minimum, I cannot decide if the 4th is necessary or not.
For me "dev" would mean what is on my box and nowhere else. This of course would be necessary.
"prod" is where the business makes money. So it is necessary.
Anything else is optional.
A "test" one is only reasonable if it is in fact used. And used consistently. This can often require dedicated QA.
You didn't mention "build" which is something I prefer. It is doable in "dev" but I prefer that everything is blown away first and that is problematic on "dev".
As for "train" that presumably would be a mirror of "prod" with less control and need for stability. Some businesses would require it. It can be available in house and/or externally. It would require a business driver rather than a development process driver.
You can also have "integration test", "system test" and "user acceptance test".
In a previous life, we had one system (as in "app", but it was mainframes not PCs). Three copies - dev, test, prod. (Oh, and test was hot standby for prod. Testers knew that their system could disappear at the drop of a hat if prod hardware chucked a wobbly.)
All worked fine until a second system was brought in (which of course had to interface with the first one). After a while, it became obvious that we needed another test copy of each system. Basically, to test a change for system A (which is going in as an isolated change, not a big-bang upgrade), you need a clone of system B prod. This is different from B test, where the B testers are playing with new stuff which will go into B prod down the track. We wound up combining that integration testing function with user training, which wasn't ideal but did save the odd megabuck's worth of big iron.
I'm not even sure if I can ask this question properly (shows how unclear I am about it myself).
So I developed a small part of a rather complex software. I am to run a system test on this software (the whole thing) to test its error handling procedures.
But it's not going so smoothly.
It's alright for those errors that I can actually cause (e.g. run the software without some essential hardware).
But of course I can't generate errors such as "Hardware broken" or "Hardware is connected but not responding" as there is a chance of actually doing harm to the hardware.
So I need a cheat.
Putting break points in the software and overwriting values is not an option because this is a system test.
So I duplicated a small part of my software and put some error testing mechanism in the second copy (let's call it the tester version). The software launches with one or the other of these versions depending on the registry value I set.
The problem is that I've limited the duplicated portion of the code, which I thought and still think is a good idea, but this means that the dummy errors can only be emitted from one place.
In reality there are many paths errors can take. Depending on the path, the final output to the user can be different.
I want to map the various error paths to help decide how best to generate the dummy errors.
It appears I need to do something like: "Generate error A as if function B caused it" and "Generate error A as if function C caused it" etc
So I need a mapping from error A to functions B and C, and so on.
Is there a clever way of doing this?
Or maybe a better question would be, what is the best way to run a system test on error handling functions?
There is no general purpose easy way to do everything.
It is possible, but difficult, to use code insertion techniques to simulate any error. At best, and at the most complicated, you actually modify the code at run time to force an error.
Some people suggest using interfaces. These are outside those required by the design but are put in place solely to support testing. The problem with that is that not everything is solved with that and it might require a lot of interfaces.
One can also be creative about testing. For example if I need to test connectivity problems I can use a system call, in the test code, to drop my IP (of course I better restore it as well.) Or I can stop SQL Server pro grammatically when doing database error tests (again make sure to restart it.)
Last Visit: 31-Dec-99 18:00 Last Update: 20-Dec-13 3:13