<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1639164799743833&amp;ev=PageView&amp;noscript=1">
Building a Better Design/Development Workflow

Diagram Views

Building a Better Design/Development Workflow

Code
Published by Brad McDavid on 11.19.15

We look at how Diagram handles version control and deployment when working on a website design and development project.

At Diagram, our talented team members work on a variety of different website design and development projects every day, and this means that we not only need to coordinate our efforts through project management, but we also need to manage the actual files being worked on. In order to handle this complicated process, we’ve put together a robust workflow process, and we wanted to share some of the details about it here.

Maintaining Version Control

Keeping track of who is working on what files during a project helps us make sure our different team members don’t step on one another’s toes. One of the key parts of this process is version control. Managing the versions of files as they are updated by different team members ensures that all the latest updates are taken into account, and each team member can take changes made by others into account when performing their own updates.

There are a variety of tools available for version control, but the one we use is Git, which is a free and open source system. Using Git to create a repository of code within Visual Studio Online gives us the flexibility we need to work together on a project.

Branches and Triggers

Git uses a concept called “branching” to manage version control during a project. This allows developers to start work on something new, using existing site code as a base. Typically, there are two main branches, or versions, of a website’s code: the Development branch and the Master branch. The Master branch is the live, production version of a website’s code, and the Development branch is the version that is actively being built on. Designers and developers can create local branches as they work on modifying the site code, and their changes can then be committed to the Development branch, allowing other members of the team to incorporate their changes into their own local branches.

Changes to the Development branch are handled by build triggers. A build server listens to these triggers, and when a change is committed to the development branch, it will follow the rules that have been specified to push these changes to the shared development server. This process ensures that all team members are able to keep track of ongoing updates to the site’s code and work on the most up to date version, reducing the possibility of confusion.

Deployment

The final piece of the puzzle in this workflow is deployment, in which a build (a set of files which make up the latest changes to a website) is pushed to a server environment. Changes are often deployed to a testing environment where Quality Control can be performed to make sure any errors or issues are found and resolved before deploying the changes to the live website.

For deployment, we use a tool called Octopus Deploy, which is a great solution for pushing builds to different environments. These deployments can be automatic or manual, but we’ve found that it is best to use automatic deployments only to a certain level, and manually deploy changes to the production environment. This ensures that changes do not go live until we are absolutely sure they are ready to do so.

Streamlining the Process

This workflow process allows us to quickly and easily incorporate the changes made by one person into the branches others are using for their design and development tasks, and then deploy these changes to multiple environments, including the production version of the website. Since making manual changes to a website is prone to error, this process eliminates that possibility, making sure that all steps of a deployment are followed correctly.

We find that it is especially beneficial for clients who utilize a development retainer; once the deployment system has been set up for them, proceeding through this workflow and deploying changes can be done much more quickly and efficiently, allowing us to provide them with the best use of their retainer time.

Do you have any questions about our design and development process? Do you want to know more about our development retainers? Please contact us to speak to a Solutions Engineer, or feel free to leave a comment below. We’d love to hear from you!

Have Questions About This Post?