6 ms·

I am doing some very straightforward asp.net deployment using git, TeamCity, nunit, and powershell. If the gauntlet of (unit-integration-acceptance) tests (in

I am doing some very straightforward asp.net deployment using git, TeamCity, nunit, and powershell. If the gauntlet of (unit-integration-acceptance) tests (in the master branch, naturally) all pass, the code is deployed to a staging server. Then there are some tests which run against staging. If those tests all pass, then the artifacts for the new version of the site are copied into a new directory (side by side) on the server. finally, a powershell script tells IIS to serve from the new directory. End result? Deployments are zero-downtime non-events tha happen multiple times daily. Rollbacks are trivial (and rare). Any not-yet-ready for prime time code can be checked into any other git branches. Database changes? I have a tiny bit of code, called from Application_OnStart that checks to see if it needs to do any CREATE TABLE or ALTER TABLE statements. Sure, I had to create all of this stuff myself, but it's all crazy simple, reliable, and does just what the project needs. Maybe someone could make some product to handle all of this, but the flexibility of linking together the best tools for the job wins for now. Also, it's just easy.

sajidnizami 16y ago
I am with you. I've just written powershell scripts that work in the following manner. 1. Make a dated folder and copy the new build to the folder on all servers. 2. Point IIS to the folder on all servers. Just in case a backup powershell script is kept. It works by just pointing to the previous dated folder of the build. Not sure why this is such an issue. Solutions can get complicated and I don't think any tool can work properly in all scenarios especially when downtime is a concern. Thats why scripts exist. Currently my solution is on Amazon, and if there was a way I'd integrate the load balancer with the scripts so that when a server is being updated load balancer doesn't send requests to it. However IIS is fast enough so this is just part of a wishlist.
notJim 16y ago
I think your solution is the mishmash of products (to paraphrase) that the author of the article describes. It's absolutely possible to do this, and do it well (the company I worked for previously did it for years before finally moving to capistrano), but the point is, that means every dev team in every company is spending precious time figuring out how to do this, writing the code, testing it, debugging it etc. When the developer who wrote it gets hit by a bus, someone has to go through his/her code and learn it so that it can be maintained. The alternative would be to have a standardized tool (like capistrano) that is commonly used.
- MartinCron 16y ago
  I guess that after trying to use "this will do everything for everyone" solutions (exhibit A: TFS). I am convinced that the time cobbling together a mishmash is less than the time spent fighting the backwards assumptions that the all-in-one solutions require.
  - notJim 16y ago
    That's kind of like saying, "Well, I tried out visual basic, but it sucked, so I decided to cobble together my own language." Pointing to a specific poor implementation of an idea does not invalidate the idea itself.
    - MartinCron 16y ago
      There is a huge difference between writing your own language and writing a 4 line PowerShell script. Really, the only gap I had to fill between the high quality parts that I'm already using (nUnit, TeamCity, etc.) was a tiny script to copy files + reconfigure IIS
robconery 16y ago
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
lscharen 16y ago
That's similar to the setup we've put together at our company. * Subversion for source control * Jenkins for building/testing/deployment coordination (each project has a Build, Push to Test Server, Integration Test Suite, and Push to Production set of jobs) * NSIS to build installers * Migrator.NET for database schema migration and rollback * PsTools + NAnt + Robocopy + Misc. Utils to deploy to remove server Our deployment process (managed by Jenkins), looks like this: 1. Pull code from SVN 2. Build the code 3. Run unit tests 4. Build the database migrations 5. Build the installer 6. Copy the installer to the test server 7. Use PsExec to run the installer 8. Copy back the install log to the build server 9. Build the integration test suite 10. Run integration tests (usually Selenium + NUnit) 11. Copy the installer to the production server Final deployment is done from within Jenkins, too, but is a manual process for now. And by "manual" I just mean that someone has to click the "Run Job" button. Sure, it's not an "integrated" solution, but I don't really see how I'd have needed less control or granularity if I were building and deploying on Linux and didn't use Ruby.
mountaineer 16y ago
While straightforward and simple it is not, this is what I'm working towards as well with CC.NET/msdeploy. For QA builds, I manually trigger a CC.NET job that builds and deploys, but with msdeploy it overwrites what's on the QA server, providing no rollback capability. For production builds, I trigger a cc.net project that just builds, then I manually push the bits to production servers, copying files from build server to production servers, setting up side by side versioned folders, and update IIS home directory for the web site. I'd like to automated, but transport is my biggest roadblock. I'm curious, how does the new version get "deployed" to a staging server and is it "copied into a new directory" on the production server (UNC, FTP, ?).
- MartinCron 16y ago
  I solved the transport piece by installing a TeamCity build agent on my production server (which is kind of wonky, but whatever). The only build project it's capable of running is the powershell script that copies the artifact files and re-points IIS. Where does it copy the files from? I set up a TeamCity artifacts dependency, so the "push to production" script doesn't run until the latest known good artifacts are downloaded from the TeamCity server.

sajidnizami 16y ago

I am with you. I've just written powershell scripts that work in the following manner. 1. Make a dated folder and copy the new build to the folder on all servers. 2. Point IIS to the folder on all servers. Just in case a backup powershell script is kept. It works by just pointing to the previous dated folder of the build. Not sure why this is such an issue. Solutions can get complicated and I don't think any tool can work properly in all scenarios especially when downtime is a concern. Thats why scripts exist. Currently my solution is on Amazon, and if there was a way I'd integrate the load balancer with the scripts so that when a server is being updated load balancer doesn't send requests to it. However IIS is fast enough so this is just part of a wishlist.

notJim 16y ago

I think your solution is the mishmash of products (to paraphrase) that the author of the article describes. It's absolutely possible to do this, and do it well (the company I worked for previously did it for years before finally moving to capistrano), but the point is, that means every dev team in every company is spending precious time figuring out how to do this, writing the code, testing it, debugging it etc. When the developer who wrote it gets hit by a bus, someone has to go through his/her code and learn it so that it can be maintained. The alternative would be to have a standardized tool (like capistrano) that is commonly used.

MartinCron 16y ago
I guess that after trying to use "this will do everything for everyone" solutions (exhibit A: TFS). I am convinced that the time cobbling together a mishmash is less than the time spent fighting the backwards assumptions that the all-in-one solutions require.
- notJim 16y ago
  That's kind of like saying, "Well, I tried out visual basic, but it sucked, so I decided to cobble together my own language." Pointing to a specific poor implementation of an idea does not invalidate the idea itself.
  - MartinCron 16y ago
    There is a huge difference between writing your own language and writing a 4 line PowerShell script. Really, the only gap I had to fill between the high quality parts that I'm already using (nUnit, TeamCity, etc.) was a tiny script to copy files + reconfigure IIS

robconery 16y ago

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

lscharen 16y ago

That's similar to the setup we've put together at our company. * Subversion for source control * Jenkins for building/testing/deployment coordination (each project has a Build, Push to Test Server, Integration Test Suite, and Push to Production set of jobs) * NSIS to build installers * Migrator.NET for database schema migration and rollback * PsTools + NAnt + Robocopy + Misc. Utils to deploy to remove server Our deployment process (managed by Jenkins), looks like this: 1. Pull code from SVN 2. Build the code 3. Run unit tests 4. Build the database migrations 5. Build the installer 6. Copy the installer to the test server 7. Use PsExec to run the installer 8. Copy back the install log to the build server 9. Build the integration test suite 10. Run integration tests (usually Selenium + NUnit) 11. Copy the installer to the production server Final deployment is done from within Jenkins, too, but is a manual process for now. And by "manual" I just mean that someone has to click the "Run Job" button. Sure, it's not an "integrated" solution, but I don't really see how I'd have needed less control or granularity if I were building and deploying on Linux and didn't use Ruby.

mountaineer 16y ago

While straightforward and simple it is not, this is what I'm working towards as well with CC.NET/msdeploy. For QA builds, I manually trigger a CC.NET job that builds and deploys, but with msdeploy it overwrites what's on the QA server, providing no rollback capability. For production builds, I trigger a cc.net project that just builds, then I manually push the bits to production servers, copying files from build server to production servers, setting up side by side versioned folders, and update IIS home directory for the web site. I'd like to automated, but transport is my biggest roadblock. I'm curious, how does the new version get "deployed" to a staging server and is it "copied into a new directory" on the production server (UNC, FTP, ?).

MartinCron 16y ago
I solved the transport piece by installing a TeamCity build agent on my production server (which is kind of wonky, but whatever). The only build project it's capable of running is the powershell script that copies the artifact files and re-points IIS. Where does it copy the files from? I set up a TeamCity artifacts dependency, so the "push to production" script doesn't run until the latest known good artifacts are downloaded from the TeamCity server.