Working with web applications – Development and Deployment

An insight into the project management and collaboration of Viking Software’s Web Team.

This is the second half of our two-part series about how Viking Software works with Web Applications. In the first post, which you can read here if you missed it, we went through the phases of a web app development project, and how we start up the process.

In this post we move on to the actual development, and how we manage testing, time management, deployment and hand-off, while working with both frontend and backend teams.

Development and testing phase

In the development phase, but before the actual development start, we work out a plan for a final deadline and the core functionalities/features. When these are defined, we can plan out the milestones for the entire project.

An example of planning:

In the start-up phase, we defined a list of core functionalities together with Client X. Our Web Team then moves on with the development planning, where we need to identify Backend and Frontend specific functionalities, while outlining the core functionalities more thoroughly. They define how many milestones they need to pass, and specify whether these are Frontend, Backend or both, and estimate how long these milestones will take to complete. According to their plan, there are 8 milestones, and they estimate the whole project should take 9 weeks to complete.

Since our Web Team has both a Frontend and Backend department, they need to split up the project into these two areas. It is therefore not unusual for one team to finish their part of the milestones, while the other team keeps working on their part. This is why a precise plan of milestones makes it possible for both teams to work on different milestones, while still working together.
Viking Software uses GitLab’s milestones, which can be found at the root of the GitLab Project Directory under Issues.

Ideally, we set the estimated finish time to be one or a couple of weeks before the final project hand-in. This makes it easier for us to deliver within deadline, even if we run into obstacles along the way.

The benefit of gaining a structure, like the one in the example, is that it gives the project manager and the team better time management. The milestones coupled with weekly team meetings keep the team on track and focused while helping them meet the final deadline.

When Viking Software uses Milestones, it could look something like this on Gitlab’s project milestones:

The above picture is from an already completed project, but it shows how easy it is to have an overview of the deadline and issues that have been resolved.

An example of time management:

We are halfway through the development project, and Client X has realised that they need a different method for deployment than what we first agreed. We agree that this deployment method makes more sense for their project, but inform the client that changing the method will cause the deployment to get pushed back 3 weeks. Client X understands that a change in plans will affect the timeframe of the project and are satisfied that they are given a new deployment date, so they can inform their own customer of the updated date.

The Deployment Phase

Before deployment we hand over the project to the client. There is always the risk that the development team run into obstacles along with the development, but since we hold weekly or biweekly meetings with our clients, chances are that the client are fully informed about what they will receive and when.

The hand-in can therefore take place when both Viking Software and the client decide that all agreed upon features have been developed and work as expected. We always create recap documents from the meetings we hold during the project, to ensure that there are no uncertainty on what has been decided and what has been changed during the project. This can also be used in the hand-in if required.

An example of hand-in:

While Client X is very understanding of the need to push back the project 3 weeks, they are also worried that the new deadline is very close to the deadline their own customer has given them for the project.
Due to the time sensitivity, Viking Software and Client X agree that the planned Hand-in will only be source code from a git repository, with Client X having the responsibility of hosting the application. We continue to have weekly meetings with the client to ensure that the project stays on track. With the strict deadline it is a little more difficult to create and maintain the recap documents. But by holding our weekly meetings, we identify any misunderstandings quickly and form new plans, making it possible for us to meet all our milestones and Hand-In on time.

After the planned Hand-in we begin the process of deployment. Whether Viking Software or the client are responsible for overseeing the deployment depends on the individual agreement we made in the start-up phase.
There are several ways to do the deployment, based on what works best for the client. Some of the methods include deploying to a test site while focusing on testing; or deployment to a live service, where it will be used by end-users immediately. The deployment might also include specific wishes that the client has requested, examples could be deployment requirements, guides or automatic GitLab mirroring.

When we oversee the Deployment, we take heed to document the crucial steps taken. By giving the client access to replicate them, it becomes possible for the client to update the application on their own.

An example of deployment:

We are ready to deploy, and have agreed with Client X that Viking Software is responsible for overseeing the deployment. We are using a deployment method that keep the application’s options open for other deployment options, should Client X decide not to use the cloud services we chose for the project.
The version deployed by Viking Software is only for client in-house testing, as we have agreed that Client X will handle the hosting environment themselves. Therefore, Viking Software have prepared a guide for the client, which enables them to replicate the deployment method, the deployed test site and of course the final version of the code repository.

Final words

As you might have noticed throughout both the article and the examples, one of the key success factors for Viking Software is to maintain clear communication between us and our clients. As developers we are always prepared for misunderstandings, changed plans and unforeseen obstacles. But experience has shown us that keeping our client close during the project minimise these issues, and results in much more comfortable and satisfied clients, even when projects have to be delayed.

The Viking Software way of working on Web Applications is neither innovative nor unique. But if you’ve read all the way down to here, we hope to have given you food for thought for how you might work on your own Web Application now or in the future, whether it’s with us or another team.

This concludes the description of the development and deployment stages of a Web Application project in Viking Software. If you missed the first part of the series, where we went into the start-up phase and brainstorming part of a project, follow the link below to read the first article.

Notify of
Inline Feedbacks
View all comments