2 added 955 characters in body
source | link

Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to:

  • Share all static files such as the images, CSS or JavaScript,

  • Benefit from common code instead of duplicating it with the risk of the maintenance page being not properly updated when the web application itself changes.

You probably won't be able to share everything, especially since, I presume, your web app uses templates while the maintenance page is static, but it's still much less hassle than to maintain a different branch or repository.

You can then switch between the web application and the maintenance page by changing the configuration of the server (like an automatic redirection of any GET request other than favicon.ico and robots.txt to the maintenance page, and an HTTP 500 for POST requests).

Note that when your web application will grow, you'll be looking into more user-friendly ways to put your web app on maintenance anyway. This includes:

  • Having a read-only flag, similar to Stack Exchange read-only mode which prevents any one to log in and post, comment and upvote.

    A similar technique is used on other large websites as well; for example, on B&H, one of the largest e-commerce websites for photographers, you are sometimes unable to purchase products, while you can still browse the catalog.

  • Having solid infrastructure which makes it possible to bring one server offline, do maintenance on it, bring it online, and do the same thing with another server.

    This approach is more advanced, since it doesn't disturb the end users: for them, the website is always online, and all the operations they were doing when being switched from one server to another are preserved.

Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to:

  • Share all static files such as the images, CSS or JavaScript,

  • Benefit from common code instead of duplicating it with the risk of the maintenance page being not properly updated when the web application itself changes.

You probably won't be able to share everything, especially since, I presume, your web app uses templates while the maintenance page is static, but it's still much less hassle than to maintain a different branch or repository.

You can then switch between the web application and the maintenance page by changing the configuration of the server (like an automatic redirection of any GET request other than favicon.ico and robots.txt to the maintenance page, and an HTTP 500 for POST requests).

Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to:

  • Share all static files such as the images, CSS or JavaScript,

  • Benefit from common code instead of duplicating it with the risk of the maintenance page being not properly updated when the web application itself changes.

You probably won't be able to share everything, especially since, I presume, your web app uses templates while the maintenance page is static, but it's still much less hassle than to maintain a different branch or repository.

You can then switch between the web application and the maintenance page by changing the configuration of the server (like an automatic redirection of any GET request other than favicon.ico and robots.txt to the maintenance page, and an HTTP 500 for POST requests).

Note that when your web application will grow, you'll be looking into more user-friendly ways to put your web app on maintenance anyway. This includes:

  • Having a read-only flag, similar to Stack Exchange read-only mode which prevents any one to log in and post, comment and upvote.

    A similar technique is used on other large websites as well; for example, on B&H, one of the largest e-commerce websites for photographers, you are sometimes unable to purchase products, while you can still browse the catalog.

  • Having solid infrastructure which makes it possible to bring one server offline, do maintenance on it, bring it online, and do the same thing with another server.

    This approach is more advanced, since it doesn't disturb the end users: for them, the website is always online, and all the operations they were doing when being switched from one server to another are preserved.

1
source | link

Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to:

  • Share all static files such as the images, CSS or JavaScript,

  • Benefit from common code instead of duplicating it with the risk of the maintenance page being not properly updated when the web application itself changes.

You probably won't be able to share everything, especially since, I presume, your web app uses templates while the maintenance page is static, but it's still much less hassle than to maintain a different branch or repository.

You can then switch between the web application and the maintenance page by changing the configuration of the server (like an automatic redirection of any GET request other than favicon.ico and robots.txt to the maintenance page, and an HTTP 500 for POST requests).