The purpose of a Go-Live checklist is to make certain that you have covered all your bases, run all your tests, allowed the client to check your work and approve it, make sure there are no regressions, and make sure that you have any special steps documented and ready to be followed.
Planning a site is more than just the design and architecture phases I previously spoke about. Your plan needs more than an outline to guide you. It needs something that will help keep you on track.
This audit was a first of its kind for me and for the PHP/Drupal Practice (as far as I am aware). We had no guidelines, framework, or basis to do this. So I set out to come up with a useful audit that can provide valuable feedback for the client to help improve their website.
Traditionally the way a developer handles this is they have an event that is triggered by some action, such as on slide change, where it finds the iframe for the video player then copies the contents of the "src" attribute into a benign attribute such as "original\_src" and then changes the contents of src to either empty or an image of some sort.
Automated processes are now the norm in the programming industry. We use them for everything from retrieving or sending data to cleaning up caches. We also use them for deploying code reliably to our various environments.
The purpose of this article is to provide a quick outline for the process we use at VMLY&R to design and architect a website. In the future, I will provide an in-depth walkthrough of this process with a hypothetical project.