4 ms·

Why would you push from your Build Server? It has nothing to do with deployment (in concept). Your build server has everything to do with deployment. Your bui

Why would you push from your Build Server? It has nothing to do with deployment (in concept). Your build server has everything to do with deployment. Your build server should be the only place production builds should ever come from. What you seem to be suggesting is replicating a build server for deployment. To me that seems like a violation of SOC and DRY -- but applied to infrastructure rather than code. Once you break out staging from production, which you should do anyways, I don't think there's any issue left from the things you listed. And the additional benefit is I don't have to learn another framework like Capistrano. With that said I do think deploying w/ ASP.NET is a pain, but not for the reasons you mentioned. But because getting the configurations working in all the right places is painful, IMO.

robconery 16y ago
I think we'll differ here - but it's a nuance really. In .NET your BuildServer has everything to do with deployment by necessity - that's not the case in other frameworks. It does work, it is convenient, but that's not a Build Server's function in concept. Which things RE deployment did I leave out? I was considering the config as part of the coding...
- Grumpydev 16y ago
  Surely with any compiled language the "build" (or build server) has everything to do with deployment? You have to build it somewhere, either on a build server, on a server elsewhere (AppHarbor style), or on your local machine. You could cut the build machine out by building locally and pushing the binaries out via git, but that's just really an implementation detail.
  - latch 16y ago
    I would have agreed with Rob, but I have to admit you make a good point. Rob is nonetheless correct that deployment in ASP.NET is poor. I think you explained one of the reasons why: static languages. It seems like you've convinced yourself that something is convenient because you feel that there's really no other solutions. I think you right and wrong...You are right because it isn't going to change, so deal with it...You are wrong because there are alternatives which have changed.

robconery 16y ago

I think we'll differ here - but it's a nuance really. In .NET your BuildServer has everything to do with deployment by necessity - that's not the case in other frameworks. It does work, it is convenient, but that's not a Build Server's function in concept. Which things RE deployment did I leave out? I was considering the config as part of the coding...

Grumpydev 16y ago
Surely with any compiled language the "build" (or build server) has everything to do with deployment? You have to build it somewhere, either on a build server, on a server elsewhere (AppHarbor style), or on your local machine. You could cut the build machine out by building locally and pushing the binaries out via git, but that's just really an implementation detail.
- latch 16y ago
  I would have agreed with Rob, but I have to admit you make a good point. Rob is nonetheless correct that deployment in ASP.NET is poor. I think you explained one of the reasons why: static languages. It seems like you've convinced yourself that something is convenient because you feel that there's really no other solutions. I think you right and wrong...You are right because it isn't going to change, so deal with it...You are wrong because there are alternatives which have changed.