I have a solution with many components with different deploy iter:

  • WebAPI backend (on IIS)
  • AngularJS frontend (on IIS)
  • A process manager (as Windows service)
  • A projection engine (as Windows service)
  • A command handler (as Windows service)

I develop all of this things. At the end of the day when something valuable is ready I need to push the updated component to the server (a local server) for testing. This usually means:

  • Build the component (remember to switch test/release environment)
  • Copy the bin
  • Open a remote desktop connection
  • Paste it on the server (after crossing the right path)
  • replace the old package (for IIS) OR reinstall the service

if the test succeds, redo this for a production environment. How can I speed up this process, and go in the direction of one click deployment? Can a tool like Vagrant be a good company? I know that this question could produce descriptive and opinion based answers but I'm stuck!

  • Use a continus integration solution? which tests, builds and finally deploys your application? – netbrain Oct 27 '15 at 10:21

Firstly you need a continuous integration server - I recommend Jenkins, its really easy to manage and is very well designed.

Once you have that set up to automatically look at your repository for changes, check them out and build them you can start looking at automating the deployment (to the test environment) mechanism.

Generally this means copying the files, but as you have services, you'll have to (at least) stop them. So I would recommend writing a script to stop the services, copy the files from a 'package' of all the files that were built and then restart the services. This script can be just a simple batch file that uses sc.exe (or net stop). If you want to get slightly more complicated, use Wix to create a msi installer and run that on the remote server in an unattended (i.e. silent) mode to upgrade the deployed installation.

I found things like One-Click to be a pain in the butt, especially when dealing with deploying to different environments - i.e. whatever deployment method you use, you want to be able to run the exact same thing on both Test and Production in turn.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.