Click here to Skip to main content
15,867,771 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
I am working on a .Net 4.0 WPF application targeting SQL 2008R2. There are 2 WPF UI's - A desktop UI and Windows 8 Tablet UI. There is also a web app. The UI's and web app all connect to the backend via an MVC 4 Web API running in IIS on both mine and the client's servers.

I use my server for testing and we also have the client's production server.

I have myself and 2 other developers all working remotely. We develop on our PC's and check into TFS online.

Then, when we're ready to test, I check out and compile.

For the UI's I publish a Click Once. Before I publish the UI's, I have to change the target IP addresses in the Config file, which I sometimes forget to do.

For the API I publish to a local folder, then copy to the IIS folder on my server. When the API is tested I repeat the copy process into IIS on the client's server by zipping the files, remote in, copy the ZIP, and extract to their server's IIS.

For DB changes I generate scripts with a tool I created (for new tables) and manually create scripts for minor changes (Column adds/changes, etc). I have SQL Compare, and sometimes I'll grab a copy of the client's DB and use it to generate a change script, then publish that script on both servers.

The problem is that this whole process is very error prone.

Now, I would like to introduce an extra layer - a Test DB, Test API, and Test UI so when I publish changes on the client's server I'm not targeting the production environment until the client is satisfied.

What's the right way to handle all of this?

Thanks
Posted

1 solution

I believe it will not give you any answer, but I'll describe you how we work - on a same dev-test-prod environment...
We have a huge application, that has web, win and mobile part. I'm working on the web part, that contains 6 portals with over 400 page together. As we are on the path to move all functionality to the web (and we have functionality of 25 years) it's a very dynamic code-base. We change code in average 30 times a day and same goes to the DB.
When one of the team finished a code change he submits it to a compiler (via source control) and got notified when compilation is done.
The next step is building a patch. The developer adds all code and data components to a list and our tool packs it into a patch.\
There is a server that every half hour runs all the patch (using some setup application) on the test servers (DB and IIS).
QA get notification about patches after update and have to test/confirm them.
Once a day - at the evening - an other service pushes all confirmed patches to the production servers (about 250 of them).
Of course patches that contains the same components can block each-other in the confirmation queue...
Now you may expect to me list all the tools we use in the process, but I cant'...
All the process powered by software developed - and maintained - in house over the years, however I thought that describing our process in a resembling environment can give you some ideas.
(A do know tools of TFS that can help you with such process, but never used them)
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900