Deploy Phase

Deployment is the final phase of the production, where the completed project is made available for public use. This process involves transferring all the components of your digital project from a local development environment to a live production environment.

It's an exciting time, but also one that requires careful planning and execution to avoid disruptions or user experience issues on the production environment - which can be disastrous for your client and agency.

Before deployment, a series of steps must be completed to double, nay tripe-check the readiness of your project. This may involve conducting final testing rounds or performing code reviews for quality assurance. All these efforts are aimed at ensuring a smooth transition from development to production and preparing for potential troubleshooting.

Here is my checklist of things to verify with developers in the context of a website production.

Quality Assurance (QA) testing is a vital step in the deployment phase. This process involves meticulously combing through the project to identify and rectify any issues that might affect its performance or user experience.

Initially, this testing is conducted internally by your team. Once you're confident in the project's stability, involve your client in the QA process. This not only bolsters their confidence in the final product but also offers valuable insights from their perspective.

The extensiveness of this process varies widely from agency to agency, but if you handover a poorly tested product to your client they will lose all confidence in your ability and attention to detail. If you feel like testing is secondary in your agency or studio, I would recommend hiring an external QA engineer to test the product for a few days - the cost is minimal and the results are essential to a final deployment.

This is mandatory on e-commerce products or websites where the client’s business is at stake.

Deployment typically involves building a second distinct environments: you’ve already been using staging, now the team will set up a production environment.

The production environment is a replica of the staging environment. The staging environment is used to help detect and fix any issues that might have been overlooked during development, when your client or development team make updates to the website these are previewed on the staging environment.

Once testing on the staging environment is complete and the project is considered ready, it is then deployed to the production environment where end-users can access and interact with it.

There are various deployment strategies that you can choose based on the nature of your project and your team's capabilities. Your technical director may opt for manual deployment, which involves directly transferring the codebase and assets to the production server. Alternatively, your team might automate the deployment process using Continuous Integration and Continuous Deployment (CI/CD) pipelines if there are a lot of regular updates planned.

Sometimes the client will be responsible for their own deployment and hosting, you will need to make sure to have your team available to test the product on a dummy environment that belongs to the client (which might not be set up exactly like your internal team’s local environment), there will likely be bugs which are more difficult to communicate since your team won’t have access to the console. If this is the case you may need to scope technical support for the client, either way make sure documentation is clearly provided in your team’s code repository.

Each strategy has its pros and cons, and the choice depends on your project's specific needs and the technical capacity of your team. It’s just useful to be aware of the different options and that both the client and your technical team will need to agree on one.

Deployment is not the end of the project's life cycle. After your project goes live, it requires ongoing maintenance to ensure its smooth operation. This might include bug fixes, feature enhancements, and regular checks for performance and security.

It's important to prepare for this phase and allocate resources accordingly to ensure the project remains viable and effective over time.

Despite your best efforts, there may be some surprising issues during or after deployment. Therefore, it's useful to have a rollback strategy in place, a plan to revert the project to its previous stable version if needed. This may involve backup procedures, version control systems, and clear documentation of each project iteration.

This isn’t necessarily our role but it is helpful to ask the development team if they have this in place, so that you can reassure the client as to contingency options should something break.

Finally, when the project is stable and ready for use, it's time to officially hand it over to the client. You’ll provide them with necessary documentation and training on how to manage and maintain the project.

You’ll probably be assigned to another project already at this point, but this handoff could well be the last time in a while that you communicate with this client, so make it a priority in order to leave a good last impression! Make sure they feel comfortable and have everything in hand, that they understand the reporting or escalation process if there is one, and that they’re welcome to work with you again anytime :)