The Stages of Development
1. Information gatheringWhen a project is first conceived, requirements of what should be accomplished throughout the project are set between the Project or Client Manager and the client. Before we begin, depending on the level of effort and complexity of a project, we create a specifications document to gather and mutually agree on a set of requirements and details. This information is used as a guide for the developers throughout the duration of the project, and ensures that all requirements and specifications are met by the time of deployment.
As an example, let’s say you want a page on your website to dynamically display all employees within you company. Currently, the employees are listed out on the “About Us” page on your website, but this is static information. A user will have to manually edit the page to update it. For this project, you and the Vanguard Project Manager have decided in the specifications document that we will now store this information in a database, which will be hosted on a different server than your website. Our developers will create a webservice to return a list of employees, so that the administrator of the site can make the updates in the database, drag and drop a widget on the page, and the website will update the list of employees on this page on a nightly basis. A developer will also need to style it, so it matches the branding and is aesthetically pleasing for the front end users.
2. DevelopmentOnce the specifications for the project have been established between the Project or Client Manager and the client, the development team receives the requirements and begins the process of development. Vanguard does not make changes in the production (or live) environment, as it is a high risk in the instance that something goes wrong. We utilize a development environment to protect the content and functionality of your live site.
For our example, at this point in the project the developers use the code to parse out the data provided by the webservice. Now that the code has finished, and the developers have implemented the requirements, the next phase can begin. How do we know if it works?
3. TestingOnce the development has been completed, we will need to do QA (Quality Assurance) to test the functionality and styling of the new changes. This is where we run through a list of scenarios to test the efficiency of the program. The developers will set up a test environment that mirrors the production environment. A testing environment, sometimes called a UAT (User Acceptance Testing) or beta environment, is a crucial part to any development. You need this environment to be as close to the live production environment as possible. We will often initiate a content freeze, where admins and back end users should not make any changes to the site. If changes are made, they may lose all their work when the work is moved to the production environment.
Using our employee list example, during QA we encountered an error because one server only allows for certain variables and another server doesn’t. It was discovered that this was because one server had the latest windows patch, but not the other. The code for the webservice works, but when the code is moved to the other server it no longer does. It is often the case that servers will be cloned to ensure that they are the same. If we did not test it before moving it live, the front end users visiting the site would see the error as well. This is why testing is so important.
The QA is now complete, and it is time to move this project to production. When deploying code to production, the first consideration should be timing. A question that is asked often is “Will deployment interrupt the website, causing the site to go down or become unavailable?” The answer is: it can. This is why we recommend a deployment time when the site is less utilized and has the least amount of traffic. Another thing to consider is how much effort will it take to roll back changes, if needed. If there are any issues with the move to production, the developer is prepared to revert changes back.
Once the code is deployed, make sure you test the code again in its new environment to ensure the release didn’t create any side effects. For example, a side effect might be if 10 people access the page where the changes were made, the site crashes. It is important to monitor these changes and report any issues to the developer ASAP.
If you have any questions regarding the different stages of development, feel free to reach out to your Vanguard Client Service Manager.