Introduction

The big day has finally come. After months of planning meetings, design iterations, and development efforts, your web application is ready for launch! Discussions around deployment strategy and schedule are starting to take shape, but what does “deployment” mean, what does it entail, and what are some things to keep in mind as this milestone approaches?

Deployment: What Exactly Do You Mean?  

The word deployment is used in several contexts and can be more or less meaningful depending on what is actually being deployed. Technically speaking, a deployment is whenever new code or adjustments to existing code are pushed to the live site or application. As a user, it’s likely that you don’t notice the majority of deployments for some of your favorite apps, especially if the changes are minor or address background functionality and performance. It’s also extremely common to bundle and release multiple features and UI adjustments together; those reoccurring system updates for your phone or computer are great examples. Then, there are those extra-special deployments which are far more monumental: a completely new or rebuilt application is made public for the first time. This post is focused on this last deployment scenario. 

Save the Right Date

Imagine this: Everything’s ready to go. You schedule the deployment of your rebranded, rebuilt eCommerce store for Friday at 11:00 pm. On paper, this seems like a great time as it will hopefully mitigate the consequences of site downtime. However, when you go to check out the site early Saturday morning, all you see is a 500 server error message on what should be your store’s home page. In a panic, you try to contact the development team, but you aren’t able to get ahold of anyone. While this might sound like every business’ worst nightmare, this situation might have been avoided by simply scheduling the deployment for earlier in the week. We typically recommend deploying on a Monday or Tuesday and avoid setting deployment dates too close to holidays/weekends. If the new application will be replacing an existing product, scheduling a late-night deployment might be worth considering. If unanticipated bugs or errors are realized post-deployment, launching earlier in the week (either during or after business hours) provides greater assurance that the support team will be available to come to the rescue.

Getting to Launch: What’s Happening Behind the Scenes

  • Production environment setup and data migration (if applicable)
    Up until this point, your application has likely lived in a staging environment. A staging environment is a sort of “sandbox”, where functionality and interface improvements can be demoed, tested, and approved in a setting that resembles the eventual production environment.  That being said, there may be some configurations (for storage, performance, or security) that will come into play in the production environment but aren’t really needed for staging. Once a deployment date is determined, it’s time to get the application setup in a production environment, or in other words, on the server intended to house the public site. If real content or information was already inserted into the staging site but should also be present in the live application, some additional time needs to be set aside for data migration. 
  • Backup Configuration
    If your new application instance is replacing an existing one, it’s highly recommended to archive those old files in a safe place in case you need to roll back to the previous instance. It’s also a good time to get a backup schedule in place for the new application’s configuration files and database. In the event of a security breach or site crash, regular backups will mitigate data loss and help get your site up and running sooner. 
  • SSL Installation 
    SSL certificates offer an added layer of security to your web application by ensuring that all information passed between clients and servers is encrypted. Having SSL enabled has been an industry standard for quite some time and some search engines will go so far as to penalize your site for not having an SSL certificate in place. You can quickly tell whether or not a website has SSL enabled by looking at the address bar: the “s” in https:// indicates an SSL. To avoid potential penalties and to adhere to current security standards, we recommend that your web application has an SSL certificate installed either before or shortly after deployment.

  • DNS Updates
    In some cases, this is the final “switch” that will replace your old site with the new one. However, updating the DNS records is only required in a few common scenarios: 

    a. The application will use a new domain name that wasn’t in use previously. 
    b. The new application will be hosted on a different server than the domain was previously pointed to.
    c. Both a. and b.: The application will use a different domain name and will be hosted on a new/different server. 

    If the application will continue to use the same domain name and will reside on the same servers as the previous instance, there is no need to update the DNS records. In this case, the final “switch” will take place once all the new code files have been uploaded to the production server.

    In the event that a DNS switch is required and after the records have been updated, the only thing preventing you and the rest of the world from viewing the new site is the time it takes for those DNS changes to propagate. Hosting providers warn that this can take between 24 to 48 hours, but we usually see this transition happen much faster (between 15 minutes and an hour).

    Additionally, there are two other variables that may prolong the unveiling of your new site: TTL and caching. In the context of DNS, TTL is how often your domain is verified with the name server. It’s often set to 24 hours but can be manually adjusted through your hosting provider. Failing or forgetting to set TTL closer to 5 minutes might be the reason you aren’t seeing your new site right away. Secondly, if the issue seems to be isolated to a specific device, you may just need to clear your browsing history/caches/cookies or do a hard page refresh (holding down shift and clicking on the refresh/reload button on your web browser).

    To read more about domain names, DNS, and how website hosting works, check out one of our other posts here.

Some Other Pre-Deployment Items (if applicable)

  • Redirect strategy implementation
    If your web application is a rebuild, it’s likely that there are specific URLs (that users have bookmarked and google has indexed) that won’t exist on the new site. Prior to deployment, we’d recommend identifying these URLs and implementing a redirect strategy for each of those individual pages.
  • Email Setup
    Does your new site have a form that should send a message to a specific email inbox? Whether you are using a third-party service to manage submissions or not, verifying that transactional emails are set up and working in the production environment is important prior to launch. 

Conclusion

Deployments can come in all different shapes and sizes. The kind our clients tend to worry about the most involves the initial launch of a new or rebuilt application. If planned and scheduled properly, deployment days can be relatively seamless and uneventful (in a good way).