4 ms·

I don't see how this is "straightforward". You have to have a server that runs TeamCity - which means installing TeamCity and setting up a build config/environm

I don't see how this is "straightforward". You have to have a server that runs TeamCity - which means installing TeamCity and setting up a build config/environment. This is all well and good for most teams - it's needed to keep the team from checking in crap. But you're using that setup to deploy your code - this is the missing piece to me. Why would you push from your Build Server? It has nothing to do with deployment (in concept). Moreover you say that "Rollbacks are trivial" - which is hardly the reality for most people. How do you rollback a push from your BuildServer? Manually? How do you alter your DB Schema? What if your deploy screws up your DB Schema? I guess what I'm asking for is a bit more detail here - you're sort of waving off everything I posted about (and experienced over the last 12 years)...

kenjackson 16y ago
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.
MartinCron 16y ago
I am not sure what you mean by "have to run TeamCity". This is 2011. If you are not running some CI server, you are doing it wrong. Full stop.
MartinCron 16y ago
Why would you push from your Build Server? Why wouldn't you? Seriously. The role of what we call "build servers" has been dramatically expanding. When I started in this business, nightly automated builds were the state-of-the art. Then we went to automated build systems that would build whenever new code was checked in. Then the build systems would run tests as part of the build. Then the build systems would spit out reports of automated test coverage so you could know if you were missing something you thought you had covered. Also, I wouldn't ever deploy production code that wasn't built by the build system. So I'm having trouble with the "nothing to do with deployment" argument. It has everything to do with deployment. I don't consider my TeamCity install a "build system" I consider "building the code" a subset of the overall Continuous Deployment system that's powered by TeamCity (which is amazing, cross-platform, and free for small teams) The end point of all of this is that instead of releasing every few months or weeks, I can release every few hours or minutes. Basically, every single change that isn't demonstrably broken gets released without us even thinking about it. It's transformative. What's the safest change you can make to a stable production system? The smallest change possible. When do your customers want to get their hands on a bug fix or a new feature? Right fucking now. If something does go wrong, how many changesets do you want to go through to try to find the problem? As few as possible. One is ideal. How many new features and fixes do you want to have to roll back if something goes wrong? As few as possible. One is ideal. Some specific questions: Rollbacks are done by just re-pointing IIS manually. I've only had to do it once. Alternatively, I could have backed out the change and pushed that through the continuous deployment system. As far as DB Schema changes go... Again, the safest change to make is the smallest change possible. Generally, I make DB changes that are backwards compatible (adding new tables, adding columns to existing tables) so if I need to roll back the code, it's just good. If you're tightly coupled to a lot of logic in stored procedures (I'm not) you're going to need to make their changes backwards-compatible (generally by using default parameters) or embed a version number in the procedure name (e.g. "InsertEntityV2", etc.) to let the two versions of the proc live side-by-side. If I need to make some sort of breaking schema change, I would have to do a scheduled downtime and handle that particular deployment mostly manually. As far as I can tell, there's no real easy way around that problem (IMVU also does their schema-breaking changes outside of their continuous deployment scenario).
- 16y ago
mountaineer 16y ago
I've done projects where I'd wing it out from my box in lieu of having a build server. Usually works fine, but I've shot myself in the foot enough to know that if you can spare the time and resources to get a build server up and running to be an independent voice in the source control chain, it tends to be worth it. I do tend to agree that the focus on deployment should be interaction with the source control repository and doesn't require a build server, I just like that added protection of the build server being the one to do that interaction when it comes to releasing code.

kenjackson 16y ago

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.

MartinCron 16y ago

I am not sure what you mean by "have to run TeamCity". This is 2011. If you are not running some CI server, you are doing it wrong. Full stop.

MartinCron 16y ago

Why would you push from your Build Server? Why wouldn't you? Seriously. The role of what we call "build servers" has been dramatically expanding. When I started in this business, nightly automated builds were the state-of-the art. Then we went to automated build systems that would build whenever new code was checked in. Then the build systems would run tests as part of the build. Then the build systems would spit out reports of automated test coverage so you could know if you were missing something you thought you had covered. Also, I wouldn't ever deploy production code that wasn't built by the build system. So I'm having trouble with the "nothing to do with deployment" argument. It has everything to do with deployment. I don't consider my TeamCity install a "build system" I consider "building the code" a subset of the overall Continuous Deployment system that's powered by TeamCity (which is amazing, cross-platform, and free for small teams) The end point of all of this is that instead of releasing every few months or weeks, I can release every few hours or minutes. Basically, every single change that isn't demonstrably broken gets released without us even thinking about it. It's transformative. What's the safest change you can make to a stable production system? The smallest change possible. When do your customers want to get their hands on a bug fix or a new feature? Right fucking now. If something does go wrong, how many changesets do you want to go through to try to find the problem? As few as possible. One is ideal. How many new features and fixes do you want to have to roll back if something goes wrong? As few as possible. One is ideal. Some specific questions: Rollbacks are done by just re-pointing IIS manually. I've only had to do it once. Alternatively, I could have backed out the change and pushed that through the continuous deployment system. As far as DB Schema changes go... Again, the safest change to make is the smallest change possible. Generally, I make DB changes that are backwards compatible (adding new tables, adding columns to existing tables) so if I need to roll back the code, it's just good. If you're tightly coupled to a lot of logic in stored procedures (I'm not) you're going to need to make their changes backwards-compatible (generally by using default parameters) or embed a version number in the procedure name (e.g. "InsertEntityV2", etc.) to let the two versions of the proc live side-by-side. If I need to make some sort of breaking schema change, I would have to do a scheduled downtime and handle that particular deployment mostly manually. As far as I can tell, there's no real easy way around that problem (IMVU also does their schema-breaking changes outside of their continuous deployment scenario).

16y ago

mountaineer 16y ago

I've done projects where I'd wing it out from my box in lieu of having a build server. Usually works fine, but I've shot myself in the foot enough to know that if you can spare the time and resources to get a build server up and running to be an independent voice in the source control chain, it tends to be worth it. I do tend to agree that the focus on deployment should be interaction with the source control repository and doesn't require a build server, I just like that added protection of the build server being the one to do that interaction when it comes to releasing code.