Attention! Three points to keep in mind when publishing a website

Hello, this is Director Nakagawa.

It's been cold in my room lately and it's hard to type on the keyboard, so I'm thinking about buying some gloves...

The direction team is responsible for creating corporate websites for B2B companies.
We often publish our clients' websites in the final stages of production, but we would like to introduce some things you need to check at this time and some things you should be careful of before publishing.

1. Check your web server specifications

Publishing a website is the final stage of production and one of the most important stages.
You upload HTML files and build a CMS on a web server, but if you don't check the specifications of your web server, you will encounter various problems when you publish your site.

For example, if you cannot use PHP, you may have to implement an inquiry form using CGI or another method, and if you cannot use SSI (server-side includes), you will need to consider a separate method of managing the source code.
For this reason, we ask our customers to confirm the following items in advance:

• Is this a new server or an existing server?
• If this is an existing server, do you want to overwrite the existing directory or create a new one?
• OS type and version.
• Availability of SSI, file restrictions, etc.
• Availability and version of PHP.
• Availability and version of CGI (Perl).
• Database availability.
• The application name for the database.
• The version of the database.
  

Checking these details will help you avoid problems when publishing, such as "SSI isn't working, so the header (the common part of the site) isn't displayed!" or "WordPress isn't working because the PHP version is different!"

In addition, by sharing this information with the production team, we can proceed with production according to specifications that are appropriate for your website, reducing risks and rework.

2. Check for additional specifications such as SSL and redirects

Next, we will look at specifications such as SSL and redirects.

Such specifications are applied to the currently published website (production environment) and it is difficult to check them in the production environment. However, because these additional specifications will change the production method and content, it is necessary to confirm with the customer whether there are any additional specifications (or whether they are necessary).

For example, if your contact form uses SSL, you will need to make site-wide adjustments, such as changing all links to the contact form on the site to use https, and conversely, changing all links from the contact form to other pages to use http.

Specifically, we check the following items:

• Whether or not SSL is used on the site.
• If you have SSL, is it just for specific areas such as the contact form, or is it for the entire site?
• If redirection is required, should it be specified globally or individually?
  

Also, if you enable SSL for inquiries, you will need to set up a system to redirect to https when the inquiry is accessed via http (without SSL).

It is necessary to check these things in advance, but there is also the rare possibility that some kind of malfunction may occur and cause the product to stop working when released to production, so if possible, it is best to test them in the production environment in advance so that you can work safely when the actual release takes place.

3. Check the steps for live release

Finally, we will review the procedures for the actual release.

The method for releasing the live version will also vary depending on the customer's environment.
For example, when you upload a new file to the production environment, your website will be temporarily unavailable.

• Who will make the final release, the customer or our company?
• What time (minute) will it be released?
• If publishing on a new server, when and who will switch the domain?
• Is it necessary to restrict display at the time of publication?
  

If your website only has static HTML, it only takes a few seconds to a few minutes to replace the files, but if you are building dynamic files such as a CMS in a production environment, it may take anywhere from 30 minutes to an hour or more.

In such cases, we create a temporary page that says something like "Server maintenance is currently underway." By doing so, you can continue with the publishing process and safely go ahead with the live release.

summary

I used to work as a coder, but it wasn't until I became a director that I started doing publishing work.
When I started doing the publishing work myself, I sometimes made mistakes and caused inconvenience to customers.

However, thanks to that, I was able to notice things that I hadn't noticed during production, and I now know how to give specific instructions to the production staff and what information I need to confirm with the customer.

Going live is a major task in website production, and if a problem occurs, it will cause inconvenience to customers and users who actually view the website.
By managing the things we've introduced today using task management sheets (task management sheets for directors using spreadsheets ) and making thorough preparations, we hope to continue to proceed with release work more safely in the future.