2 added 1816 characters in body
source | link

There is also much more to do than simply update the files: you have to handle permissions, configuration, dependencies, etc. For example, one of the issues which is often encountered by the beginners is that they keep old DLLs in /bin while adding new ones with different names: the application may still use the old ones, which creates a crazy situation where you change the code of the application, but the application behavior remains the same.

  • Permissions

    The new version may require a different set of permissions on the server.

  • Configuration

    The new version may require the Distributed Transaction Coordinator (MSDTC) service to be installed, or may want to use a different SMTP server, or have access to Active Directory, etc. This involves changing both the configuration of the application and of the server itself.

  • Dependencies

    For example, one of the issues which is often encountered by the beginners is that they keep old DLLs in /bin while adding new ones with different names: the application may still use the old ones, which creates a crazy situation where you change the code of the application, but the application behavior remains the same.

  • Data

    What if database schema changed, and the application uses an ordinary SQL server instead of NoSQL? How to perform the change in the schema? How to keep the data correct during the change?

Handling the transition between an old and a new version of the application is a hard task. A few years ago, it was one of the issues, where a new version of application was ready, but took days or weeks to system administrators to deploy. DevOps addresses this issue, but requires for the developers to describe (through code or configuration) the system which will host the application.

Compiled applications simply force/encourage to automate the process earlier.

the business contacted us to update some of the text and add a link to a new pdf document. The rest of my team were quick to say that this should not be done because the site is now live

IMO, there are no real technical reasons for this refusal; they just want to avoid doing it, because, if not automated well, the task is error prone.

What usually happens is that:

  1. The application is deployed for the first time.

  2. The team spends a few hours tweaking the configuration to make it work. Since the team was expected to deliver three weeks ago, everybody rushes, and nobody takes the notes of the changes.

  3. The application is now up and running.

  4. For a few weeks, months or years, some random people change some random stuff on the server: for example they moved a database to a different location, or the SMTP password changed, causing the changes in Web.config.

If you update the new version now, you're back to the first step, and it may take days to recover the correct configuration. Since the website is live, this should be avoided at all costs.

There is also much more to do than simply update the files: you have to handle permissions, configuration, dependencies, etc. For example, one of the issues which is often encountered by the beginners is that they keep old DLLs in /bin while adding new ones with different names: the application may still use the old ones, which creates a crazy situation where you change the code of the application, but the application behavior remains the same.

Handling the transition between an old and a new version of the application is a hard task. A few years ago, it was one of the issues, where a new version of application was ready, but took days or weeks to system administrators to deploy. DevOps addresses this issue.

Compiled applications simply force/encourage to automate the process earlier.

There is also much more to do than simply update the files: you have to handle:

  • Permissions

    The new version may require a different set of permissions on the server.

  • Configuration

    The new version may require the Distributed Transaction Coordinator (MSDTC) service to be installed, or may want to use a different SMTP server, or have access to Active Directory, etc. This involves changing both the configuration of the application and of the server itself.

  • Dependencies

    For example, one of the issues which is often encountered by the beginners is that they keep old DLLs in /bin while adding new ones with different names: the application may still use the old ones, which creates a crazy situation where you change the code of the application, but the application behavior remains the same.

  • Data

    What if database schema changed, and the application uses an ordinary SQL server instead of NoSQL? How to perform the change in the schema? How to keep the data correct during the change?

Handling the transition between an old and a new version of the application is a hard task. A few years ago, it was one of the issues, where a new version of application was ready, but took days or weeks to system administrators to deploy. DevOps addresses this issue, but requires for the developers to describe (through code or configuration) the system which will host the application.

Compiled applications simply force/encourage to automate the process earlier.

the business contacted us to update some of the text and add a link to a new pdf document. The rest of my team were quick to say that this should not be done because the site is now live

IMO, there are no real technical reasons for this refusal; they just want to avoid doing it, because, if not automated well, the task is error prone.

What usually happens is that:

  1. The application is deployed for the first time.

  2. The team spends a few hours tweaking the configuration to make it work. Since the team was expected to deliver three weeks ago, everybody rushes, and nobody takes the notes of the changes.

  3. The application is now up and running.

  4. For a few weeks, months or years, some random people change some random stuff on the server: for example they moved a database to a different location, or the SMTP password changed, causing the changes in Web.config.

If you update the new version now, you're back to the first step, and it may take days to recover the correct configuration. Since the website is live, this should be avoided at all costs.

1
source | link

ASP.NET MVC applications are compiled. This means that you can't just upload the changed files, like you do with a PHP website, for example. This also means that when you'll start to update the site, current users will be thrown away (lose their sessions, for example).

There is also much more to do than simply update the files: you have to handle permissions, configuration, dependencies, etc. For example, one of the issues which is often encountered by the beginners is that they keep old DLLs in /bin while adding new ones with different names: the application may still use the old ones, which creates a crazy situation where you change the code of the application, but the application behavior remains the same.

Handling the transition between an old and a new version of the application is a hard task. A few years ago, it was one of the issues, where a new version of application was ready, but took days or weeks to system administrators to deploy. DevOps addresses this issue.

The larger is the application, the more complicated is this task.

  • For a tiny web app, copying source files to the server is enough,

  • For something larger, you have to have an automated process which deals with the update process, and the rollback in case something goes wrong,

  • For systems even larger, at every new version, new VMs are created and deployed, and old ones are recycled, ensuring seamless transition of the users from the old to the new version.

Compiled applications simply force/encourage to automate the process earlier.