In the world of web, a deployment means pushing code updates to an environment – such as updating your production website with new features or functionality.
As one of the final stages of the development process, the deployment phase is often known as a worrisome time within a web project as changes are published on your site. But we’re here to take the stress out of deployments.
In this blog, you’ll find out…
- Why deployments have got a bad name for themselves
- How our deployment process reduces risk and downtime
- What our deployment process looks like in action
Deployment pitfalls
There’s no getting around them, deployments need to happen.
Whether you’re going through a migration project, having a new site built or simply updating what’s there, whenever a change is made to your website and a code change is needed, a deployment will occur.
A deployment comes with a list of potential pitfalls that it’s best to be aware of:
- Website downtime
- Fear of the website being taken down
- Loss of customers and revenue
- Reputation damage
- The worry of what will happen when a deployment occurs
- The unknown of how an environment will behave when code is put on it
- Doing deployments at all hours of the day (yep, even 3am) so it doesn’t affect your site and incurring a premium agency charge due to this
So, how can you avoid this list of all the things you don’t want to happen during a deployment? With a proven deployment process run by an experienced team.
Pinpoint’s deployment process
Understanding just how important a robust deployment process is, we’ve invested in building our own.
Build, test and deploy – our deployments are completed through a controlled, tried and tested process during working hours, with the added confidence of zero downtime for your customers.
Deployment pipeline
As part of our deployment process, we opt for the software Jenkins. This provides us with the support for continuous and seamless deployment delivery which runs a whole host of commands before the code even reaches our clients’ servers.
Adobe Commerce
We only build in Adobe Commerce. The platform requires code to through a series of processes every time you complete a deployment. If you’ve added or removed any code, it already knows what’s in there and what updates need to occur helping reduce risks from the off.
Pull request environments
A pull request (PR) is when you merge code within source control from one branch into another branch. Every piece of code we create and every ticket we work on is stored separately so that you have the flexibility to deploy features in whatever sequence you require.
Each branch can have a PR environment created for it. As soon as the PR is opened, an entirely new environment is formed and synced from the staging database. This means we already have all of your test environment created making it simple to develop and deploy with ease.
Continuous deployment
Zero downtime should be expected from all agencies – no matter the size. Our system means we can press the deployment button as soon as we’re ready to release an update. We have a constant development branch and production branch and then we have a branch of work that could be a new feature such as a checkout.
A pull request tells the system we want to take this piece of work in the development branch into the production branch. It then shows you all the differences at a code level and, most importantly, within an environment that allows you to check functional and visual changes before they’re published.
This provides our developers with an environment that’s built from scratch every time allowing them to check their work ahead of it going into quality assurance (QA). As work is completed, we can pass this over to the client for them to test the branch specifically and sign it off.
Our slick process allows us to continuously develop and deploy site improvements on a retainer basis with no downtime. This keeps changes and updates moving. If you need to get something live, you can – critical if you want to keep up with customer expectations in the fast-paced digital world.
Added confidence
Our process gives us the ability to have all existing code onsite. This means your pre and post release versions are on the server so if the worst did occur when we release the new code, it’s easy and quick to switch back to the old code.
This often differs to many other agency processes where they would have to sift through back-ups, or roll back individual files, or even take an entire website copy before deployment. Instead, our approach provides the confidence to build everything separately and make the switch as we need to.
Our deployment process in action
While we may have lots of processes in place, it can be run through in a matter of minutes. Let’s take a look at one of our projects, Osprey. Due to Osprey having so many language variants, this project had our longest deployment time yet – a whole 43 minutes!
However, thanks to our deployment process, the downtime was barely noticeable. 35 of the 43 minutes were done before it even reached their server, and the remainder was simply the time it took to get onto their server.
In the end, Osprey only experienced a 15 second downtime. If we were running this process manually, without our processes in place, they could have experienced the full 43 minutes as downtime.
What team Pinpoint has to say…
“With our deployment process for both production and test environments, we can now do as many as 5 deployments per day as we only require developers to support should anything occur with the build process or the live site post deployment. Using Jenkins has also drastically reduced the downtime clients used to face from approximately 15 minutes to typically less than 1 minute.
As a result, we are now able to get more work deployed to our clients with minimal effort on a more frequent basis. We are also able to isolate specific pieces of work to separate test environments. This protects the main test environment from being blocked by any potential issues introduced and leaves us with the ability to test and deploy any potential urgent issues that are logged.
On the rare occasions that something doesn’t go to plan, our developers are able to diagnose, fix and redeploy with a matter of minutes usually without any disruption to the client.” – Matt Fortune, QA Tester
__________________________________________________________________________________
Knowing that your environment has the right code and that it’s being deployed through a proven system reduces downtime and leaves no room for things to go wrong. Even better, the majority of this can be done before the code is even deployed to the server.
Processes like these are what set agencies apart when it comes to selecting the right agency for you. If you want to find out more about our development processes or you’re looking for guidance on a website project, don’t hesitate to get in touch with our team.
Share
