Jump to main content
Menu

Web Development Workflow

Development, Staging, and Production

  • The first consideration are the environments where code is being posted.
  • There are generally three environments:
    • Development - This is used for code that is in early stages or for trying out things, such as alternate approaches to functionality or a layout. This is only for developers, and may be on a server or just on the developer's local machine.
    • Staging - This is for production-ready code that you don't want available to the world and that needs testing / verification. Clients may end up viewing things here, as well as non-developer team members (project managers, quality assurance testers, etc.).
    • Production - This is the live site at the domain that users are visiting. Minified CSS and JavaScript are used in this environment.
  • For large-scale projects, especially ones where the application is being supported for many years, you are likely to have separate servers for development, staging, and production. The staging and production servers need to have the same setup for hardware and software, or you're asking for trouble (you will deploy code to production and it will fail, when it worked fine in staging).
  • For smaller-scale projects you are likely to only have two environments: development and production. In that case the development environment takes on the same characteristics and role as staging. Since these are smaller projects, you might have one server for both development and production and you could have a dev subdomain (e.g., dev.somesite.com), with the production site at the regular domain and/or the www subdomain (e.g., somesite.com or www.somesite.com).
  • Why do all of this? You don't want to be testing in production.

Controlling Access

  • Limiting access to development and staging servers is of great importance.
  • While you might think that hackers (or more benign visitors, such as the Google and Bing spiders) will not find your development and staging environments, you should think again. Security through obscurity ("they won't guess this URL or find the IP address") is not security. All it takes is someone posting a link to your development or staging sites somewhere (or even emailing them via Gmail), and you've got spiders visiting those sites and indexing them. It seems like the web search engines are even looking through domain registrations, so they will attempt to visit.
  • Corporations will limit development and staging access to the computers on their network, requiring access through a Virtual Private Network (VPN) or an office computer (accessed in the office or through a remote desktop connection client) for the sites to load. Computers outside of that protected status (outside the firewall) get blocked. Whether this is an option for you largely depends on whether you are working in an organization with these resources.
  • If you don't have that sort of setup, then you need a different strategy. If you're running on Apache or similar web servers you can implement htpasswd, which ties in with .htaccess files to prompt a user for a username and password before accessing certain directories. If you have access to cPanel (a server management dashboard) through your web host, you can configure this directory-level password protection through that tool.
  • If none of those are possible, you can at least implement robots meta tags set to "noindex, nofollow,noimageindex" to tell Google and Bing to not index those pages, not follow their links, and to not index their images. Just be careful not to accidentally deploy that to your production site! (Clients are not big fans of their site vanishing from search engines.) This will also not do anything to protect you from hackers.

Local and Server Backups

  • Having backups is essential to being a productive web developer, because if you don't have a backup your computer's hard drive will eventually crash and you will lose a lot of work.
  • On your local machine (the one where you do your coding), I recommend having some sort of backup solution. There are various cloud-based options that backup continuously, such as Carbonite.
  • And on your server(s) it is valuable to be running some sort of backup solution as well, should you need to "roll back" to a previous version of the site or application. Web hosting providers are more than happy to sell you a backup solution.
  • Having local machine and server backups is a protection against catastrophic failure (or a botched site update where easy rollback is a challenge), but they are not the entire solution.

Version Control

  • You need to have your code in a version control system, because there will be cases where you need to roll back to a previous version of a file (perhaps a few edits back).
  • Backups are too imprecise in this scenario. Restoring the server backup is a massive rollback, and you just need to go back to a previous version of one file. You might be able to get more precise restore functionality in the server backup, but it only restores a given file from a given day, and on that date you changed the file 8 times. Which one is in the back up? Even the local machine backups will not give you the precision you need - there may be multiple snapshots of the file in question, but which one do you need?
  • That's where version control comes in, and must become part of your workflow.
  • Just made a layout update? Added some functionality? Commit (check in) the modified code into the file repository, with a note giving high-level details regarding what was changed. That note is probably your best way to know which version of the file to roll back to, should you need to do so. All version control systems allow you to compare file contents to see what changed with each commit (they highlight the changes), but the notes help you to identify which code to begin comparing.
  • The best practice is small commits. Don't make 10 different changes in various parts of the code base, and check them all in at once. Modify one aspect of the website or application, then check that in. Move on to the next functionality change, get it done, then check that in. Small, incremental commits are better than huge, monolithic commits (if possible).
  • I recommend reading this guide to version control concepts to get a better understanding of the fundamentals of version control.
  • Even if you're working on your own, you need version control. This is not just about someone else overwriting your file(s) on the server and not being able to get back the code that was originally there. Trust me - without version control, this happens. Often it's a self-inflicted wound, with you overwriting a newer file with an older file, and there is no way to get back that newer file without digging into a server backup. Version control allows you to roll back to earlier versions of code and know what you changed and when you changed it.

Git and SVN

  • The most popular version control system currently is Git, and the most common place where Git is hosted is GitHub. They have a desktop client for Windows and Mac that is commonly used to check out code, commit changes, etc.
  • An older version control approach is Subversion (also called SVN). In this case you would either run your own SVN repository on one of your servers, or would use a third-party service to host your SVN repository. Locally you would use a client like TortoiseSVN, which integrates directly into Windows. There are various Mac OS X options as well, like SmartSVN.
  • The primary difference between the two is that Git is decentralized, with you having your own local repository for committing, while SVN has one centralized repository where everyone commits their changes. Both support branches, so a developer can work on their own version of the code base and then merge changes into the trunk (which is the code that eventually gets pushed to production).
  • Git is also more complicated, largely due to being decentralized. SVN is pretty straightforward: check out repository (downloading it to a location on your computer - this only needs to happen once), make changes, then commit the changes to the repository. If someone else modified the file(s) that you also changed, you need to merge the changes and resolve any conflicts. Before you do any work, you can choose to update all your files, so you pick up any edits checked in by others.

Ticketing Systems and Bug Tracking

  • Another important part of web development workflow is issue tracking and bug tracking.
  • You / your team need to know what to work on, and so there is always a need for a system to track what work needs to be done and its status (open / closed / fixed / won't fix).
  • Items in these tracking systems are generally organized into the following categories:
    • Defect / Bug - Something is not working right in the code. Often there is a level of priority/severity that can also be indicated.
    • Request / Enhancement - A change request that applies to the code base. New functionality, new content, or an update.
    • Task - Something that needs to be done that is not a defect and not a coding request. Could be related to setting up something on the server, cleaning up old log files, etc.
    • Other - Miscellaneous category for anything not fitting in the other categories.
  • JIRA is the most commonly used application for this, but there are many others out there. Often they try to also serve a project management purpose, such as Backlog by Nulab.

Slicing Photoshop Mockups

  • In many cases, you are given a Photoshop file (called a mockup or comp) showing the layout you are creating.
  • In some cases, the images will be sliced (cut out as separate graphics) for you, but it's debatable whether that saves you any time. The choices made by the designer during image slicing may not be compatible with how you want to code the layout.
  • You may also find that the designer was rushing during the slicing process and has accidentally made some images a pixel too narrow or a pixel too short, so you have to re-slice them anyway.
  • To be clear: you never want Photoshop generating any code for you, because that is not code you would ever want to use in production. You just want the graphics.
  • Photoshop may also not do a great job of optimizing files, so you will probably end up taking the Photoshop output and running it through other graphics programs / tools to further reduce file size without sacrificing visual quality.
  • From the mockup you are also determining:
    • What fonts are used and approximate text sizing (sometimes the sizes in Photoshop are a bit off, as the fonts are rendering slightly differently than they do in a browser, or the sizing units are points rather than pixels).
    • How much vertical and horizontal space are occupied by gutters / space between columns and rows.
    • Color (hexadecimal) values.
    • Any other relevant visual design details.