-1

I'm currently developing a quite large ASP.NET application which uses SQLExpress as the underlying database. The project is currently under heavy development and is covered with unit tests and regression tests. Subversion (SVN) is used as a version control system. Those tests are very important, we need to make sure that every test returns successfully.

Our current workflow looks like this:

  1. Someone commits code changes to our svn repository
  2. Coworkers will update their local repository and execute a build script which moves builds some visual studio projects and moves DLL's around

Note that the tests will not be triggered automatically!

So, here are my questions:

How does one use Continuous Integration in this setup? I found Jenkins.io after some research. Tools like TravisCI or CircleCI seem not to work with ASP.NET applications (correct me if I'm wrong). Is Jenkins suited for executing asp.net tests on every SVN commit?

I'm open for every idea and tip on how you would handle CI / automated testing in this situation.

The second question is all about using the application: How does one proper deploy asp.net applications in 2017?

Fyi there are two ways how our platform / website can be used:

  1. The application including the database will be deployed at a customer's own server
  2. The customer uses our server where the app is deployed and just connects to it

Our current setup is based on a powershell script which creates databases with tables and initial data, deployes the asp.net project, modifies config files and finally configures the IIS Webserver.

Is a container based setup like Docker the go-to way? And how would you handle the "update case"? Updating the software is not a problem on our servers, but how would you handle this if our software lies on the customer's server? I'm up for every idea. :)

  • 2
    Do you intend to use the same strategy in 2018? Or will you change it to suit the latest flavor of the week? – Robert Harvey Aug 31 '17 at 19:52
  • @RobertHarvey I'll ask the you again :) Shall I tag you? – jdstaerk Aug 31 '17 at 19:59
  • My question was somewhat rhetorical. I think you should choose the strategy that most effectively fulfills your specific project requirements, rather than following the latest fashion. I doubt that "popularity" tops your requirements list. – Robert Harvey Aug 31 '17 at 20:00
  • Mate my answer was pure irony... – jdstaerk Aug 31 '17 at 20:01
  • 2
    Actually, I'm making a good faith attempt to help you become a better programmer. Popularity is seldom a good way to make decisions. If what is considered "best practice" today is no longer a best practice tomorrow, then it wasn't really a best practice after all, was it? It was just someone's incorrect opinion. Evaluate the available options, determine which one best supports your specific requirements, and then make up your own damned mind. – Robert Harvey Aug 31 '17 at 20:04
1

Well there are a number of options and its quite detailed. Also your case is perhaps unusual in that you deploy on the customers server as well as your own.

If you have a website/application then changes are you are continuously updating it. Your CI platform might look like

  • Github: with gitflow branching
  • Teamcity: trigger on commit to develop branch
    • build solution
    • run unit tests
    • package to nuget
  • Octopus Deploy
    • teamcity triggered deployment to test server
  • Team city: build triggered by deployment success
    • run selenium webdriver UI tests against test server
  • Octopus Deploy
    • Manually triggered deploy to live with green/blue servers when you are happy.

With the database you might have a similar chain but with migration scripts

If you service is hosted in the cloud you might spin up new instances each deployment rather than deploying to the same boxes.

Now if deploying to a customers server you probably can't mandate they use octopus, so you'll need a stand alone deployment script.

Powershell is a bit old hat these days, Try Fake the F# based make script which has plugins for setting up IIS and the like. But essentially its doing the same thing.

Similarly, Jenkins can perform the same roll as Teamcity and Subversion can replace Git (if you insist on using it)

The main difficulty is not in programming the scripts to make it all happen. Its in being disciplined enough to fix the build chain when it breaks, rather than do a manual work around, or disable tests.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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