What is Deployment?
Deployment in software and web development means pushing changes or updates from one deployment environment to another. When setting up a website you will always have your live website, which is called the live environment or production environment.
If you want the ability to make changes without these affecting your live website, then you can add additional environments. These environments are called development environments or deployment environments. The additional development environments will typically be a local environment, a development environment, and a staging environment (also known as a staging site). How many environments you need is up to you and depends on the complexity of the project you are working on.
While deployment models can vary, the most common is the classic “left to right” deployment model when working with multiple deployment environments. In this model, changes are made in local, development, or staging environments (depending on the setup) and pushed from left to right through the different environments ending up in the live environment. Once this deployment process has been completed the new changes will be visible in the live environment.
Table of content
The above image shows a very simplified and classic way of handling deployments when working with websites in a CMS. You do not necessarily need all of the above environments, but the process stays the same.
By using multiple environments you get a list of advantages - the main one being, that you can make changes without it affecting your live website. Once the changes are made, tested, and ready to be pushed live, the deployment process takes care of the rest.
Which steps are in the deployment process flow?
The deployment process flow consists of 5 steps: Planning, development, testing, deploying, and monitoring.
Below we'll dive into each of the 5 steps, but before we do, we'd like to add a quick note.
The deployment process flow below covers the fundamentals, which are split into 5 steps. That doesn't mean it's the only way to do it - there very well might be a better process for you. We've tried to keep it as simple as possible to make it cover the most important parts.
If your situation requires additional steps in the process then you should absolutely do that.
1. Remember to have a software deployment plan
To make sure the deployment process goes as smoothly as possible it is best to have a deployment plan that you follow - every time. By having a plan you ensure that everything is done the same way each time changes are made. This is especially helpful when multiple users are working on the same project.
A deployment plan should include rules for when to deploy from local environments to development or staging sites as well as schedules for when new changes can go to a live environment. By having a set plan you reduce the risk of conflicts between different changes and make sure the deployment process is as smooth and easy as possible. If you're working on an open-source project it also gives you the chance to do Release Candidates and let your community test it out for any bugs you might have missed yourself.
Besides an overall plan, it's also important to plan each individual change that you're going to do. This process will be very quick for minor changes but should be much more extensive for big changes. By planning well in advance, you're much better suited to have a smooth deployment process.
2. The actual development
Once you have the plan in place, it's time to do the actual development. To ensure that any development can be done simultaneously and without breaking anything, it's important to only work on local or development environments. Once the development process is done, it's time to start testing and deploying the changes through your environment setup.
Not sure whether to work locally or in a development environment? Then take a look at the deployment best practices section.
3. Testing your changes
Testing your changes is crucial to ensure that no bugs make it into the final production environment. But testing cannot be completed without deploying your changes to new environments.
Once you've tested that all of your changes work on your local or development environment it's time to deploy the changes to the next environment in line. This should be done all the way up to your staging environment, where final QA testing should be done. If everything is properly tested and works in an environment resembling your live environment it's time to deploy it live.
If you discover bugs along the way in any environment, it's important to have a plan for how to handle these. Typically any change that doesn't pass the testing on the staging environment should be sent back to the development phase and - once fixed - again work its way through the environments.
4. Deploying changes to the live environment
Once all of the testing has been done on previous environments and any bugs have been fixed, it's time to deploy your changes to the live environment. This should be a pretty safe thing to do, but everyone who's worked with software development knows, that something can still go wrong.
So even though it's easy to stop here, it's important to include the final step of the process: monitoring.
5. Monitor your changes
Once your new changes are live and real users are actively using your website or application, it's important to monitor that everything works as intended. No matter the planning put forward, there's a chance that users encounter issues or perform actions that you did not anticipate during your planning and development.
A good tip for monitoring is to plan releases for times where the least amount of users will notice and where you have development resources ready in case something needs to be fixed. That way the number of users impacted by any bug will be minimal and you'll have people ready to fix it or roll back the changes if need be.
If you do need to roll back your changes, it's important to keep calm and have a process to handle that as thoroughly as you handle deployments.
Different types of deployment
When it comes to the type of deployment it will often be split up in a two-part deployment approach. It will typically be a split between metadata and content as these have different impacts on a new environment and need to be handled differently.
Deployment of metadata
Metadata includes changes to your code, templates, stylesheets, files, and so on. These changes will often require a validation check between environments to see if they have any unforeseen conflicts that need to be resolved. Many deployment tools will include checks for consistency and help guide you in case of conflicts.
Deployment of content
Content such as text, images, and videos are handled differently during deployment as they are less complicated to move between environments than metadata. For that reason, you will often see that deployment tools make content deployment accessible for content editors and not only for developers. That way a content editor is not depending on a developer when it comes to pushing new content to a live environment.
An example of multiple environments in Umbraco Cloud
Deployment best practices
When you're working with deployment environments it is - as previously mentioned - important to have a plan and a clear process for it in your team. To expand on that process we've gathered some best practices that are good to implement as part of your process.
Please note that the following best practices mostly deal with software and web development. If you're doing other kinds of development there might be other things to consider in your deployment workflow.
Use Git
This one might seem obvious, but having a version control system is invaluable to any good deployment workflow. Without it, it's likely that mistakes will happen if you're working in a team.
Even if you're the only developer working on a project it's highly recommended to use Git in case you need to go back to previous versions or if someone new joins your team.
Without Git it'll be hard to ensure consistency in your deployment workflow and can lead to more mistakes being made from deploying unfinished code or not having all team members work on the same version of the code.
Work in branches
As a general rule of thumb, your team should be working in branches. Doing so will make it possible to work on multiple things at the same time without them affecting each other.
An example is when a bug is found that needs to be fixed. If a developer is using a branch to work on a new feature, they can quickly make a new branch of the development environment to work on the bug. That way there'll be two different branches that won't clash or create potential merge conflicts down the line.
Working with branches also helps your Q&A Team when deploying to a staging environment. Having your changes in separate branches and merging them in will give testers a better overview of what was pushed and what they should test.
Use a local environment as your development environment
While it is possible to work directly on a development environment, it will in most cases save you a lot of time by working locally instead. By installing the website or software locally you'll be able to work more efficiently while also speeding up testing and verification of your code.
The only downside of running locally is that you have to install the website or software on your machine. But the time spent doing so is won back multiple times in the long run.
Firstly you don't have to constantly commit, push and deploy a change before you can verify if it works. And when something doesn't work (this happens to all of us) you'll have to revert it, push it again and redeploy.
Instead, you can simply run it all locally and once it's working as intended you can push it directly to the staging environment for more rigorous testing.
Review the differences before deploying to the live environment
When your testing team has ensured that it's all working in your staging environment it's finally time to deploy the code to live.
But before you make the final deployment, it's important to make a final review of the differences between your current live environment and the development environment you're pushing.
This step can definitely feel like overkill and often it might seem redundant as no errors were found. So why do we still recommend this step?
Because of those few times where it actually did catch an error.
Even after thorough testing and quality assurance, things can go wrong as soon as it hits the live environment. And once that happens it can oftentimes be very stressful to implement quick hotfixes or to do a full version rollback. Generally, you'd want to avoid this at all costs, which is why we'd highly recommend you do a final review of your code before pushing the deploy button.
Have a deployment schedule
As part of your deployment plan, we highly recommend that you include a deployment schedule as well. Having a fixed time for when new changes can be deployed to your live environment is a great way to ensure that everyone knows when new changes are coming.
It can be tempting to take a more iterative process where new changes are pushed as soon as they're ready. And while this can definitely work for some changes and some teams, there are also situations where this can have unfortunate consequences.
This is especially true with major releases where it's important to have actual human eyes and hands ready if something does not work as intended. And by scheduling deployments, your team can plan tasks and working hours around these time windows where they might need to help out with a hot-fix or rollback.
How often you should have deployment windows and what time of day you should plan them is something we'll cover a bit further down.
One last note: even if you have a deployment schedule it's always a good idea to do manual deployments instead of automatic deployments. Besides having someone do the last review, it also helps that someone from your team knows exactly when and what was deployed.
Consider having user groups with different permissions
While any developer should be able to push changes to staging environments, it can be a good idea to restrict who can deploy to live.
For smaller teams, this might not make much sense as it can create a bottleneck for getting new changes out. But if you're a bigger team with a varied level of experience between the team members it can be a great idea to only let senior developers deploy to the live environment.
This effectively ensures a higher level of control over the release flow and also means that at least one set of senior eyes have seen what is going into the live environment. If you're having a very iterative approach with rapid releases this might slow you down. Even so, since the changes being pushed are usually smaller with this approach, it probably won't slow you down that much. And if it means catching a few more mistakes, then the time saved by not having to fix bugs will make up for the time spent.
Speaking of stuff breaking...
Stay calm - even if something breaks
You just deployed to your production environment and now your website is broken. Sound familiar?
Unfortunately, these things happen - no matter how careful you are. But instead of panicking and pushing hotfixes or immediately rolling back, it's important to stay calm and make sure what you're doing won't break things even further.
First off, you should check if a rollback is even possible and if it would actually fix anything. In some situations, you might have made changes that are irreversible and where a rollback would only cause you even bigger issues.
You also need to check if it was an existing or new feature that broke. Again, if the thing that broke wasn't part of the new release it probably won't help to do a rollback.
So instead of panicking, have a plan ready and take a deep breath before going to work at finding a fix. It might seem simple, but it can help you get out of a bad situation much faster than if you jumped straight in.
What time of day should you deploy changes?
In case something does break when you deploy to your production environment, it's important to find the best time to do so. And while this time varies greatly from project to project, there are 2 questions you can ask yourself to determine when to deploy changes:
- When do you have the least amount of active users?
- When do you have someone ready to monitor and fix issues after deployment?
When do you have the least amount of active users?
Generally, you want as few people as possible to be affected by your new changes. So as a rule of thumb you should look for any time of day where the least amount of users are actively using your website or software.
For websites this can be done by looking at your chosen data analytics tools, eg. Google Analytics. In there, you'll be able to make custom reports that show you what time of day you have the least traffic as well as identifying peak hours where you should definitely not make any changes.
Besides looking at the time of day it can also be worth it to look at how user activity is spread out across weekdays.
This analysis is great, but it will often end in roughly the same answer: You should publish changes during the night. And while that might seem like a great idea if we only looked at this one question, it's important that we also take the next one into consideration.
Is anyone awake and ready to fix potential issues at that time?
If your answer is no, then deploying changes in the middle of the night might not be the best idea anyway.
Instead, you should identify time slots where you can find the best balance between the number of active users and developers ready to fix issues. This will vary greatly depending on your project and on your team, but generally, you should be able to find some options. And if you already have a fixed deployment schedule you could even convince your team to be ready at odd hours of the day. It's much easier to convince someone to come in a few hours earlier if they know it only happens once every cycle or sprint.
Although there is no perfect time to deploy, there definitely are times that are better than others.
What are the advantages of deployment and multiple environments?
Reduced risk of breaking a live website
One of the main reasons for using multiple environments and relying on deployment is to reduce the risk of changes having a negative impact on a live website. While minor changes can easily be done directly on a live website, bigger changes can be made on separate environments without the risk of breaking anything in the live environment.
When having multiple users working on the same website also ensures that no one risks breaking something due to another user’s changes.
Save time
Without the worry of breaking something on a live website, you can make changes in whichever order you prefer. This means that you can optimize your workflow of getting the changes done without any consideration to how the website looks or functions while doing it.
If you are working in a local environment you also have the advantage of changes processing faster and not be reliant on any connectivity issues.
When it comes to deploying your changes you will also save time by pushing all of your changes at the same time instead of having to do it in many smaller steps.
Time-sensitive content is easier to manage
If you are running campaigns that are time-sensitive and can only go live from a certain day or time, then running multiple environments and using deployment can save you a great deal of stress.
By creating all the content on a staging (or similar) environment you can finish your campaign without worrying about it being visible to your users. And when it is time to launch it can all be made visible in a very short time by deploying it to your live environment.
And if the deployment tool includes user roles with permission settings it is possible for a content editor to do all of this - including deploying the changes - without involving a developer in the process.
What does it mean to deploy a website?
Deploying a website means that you are deploying changes you have made to your website, typically code, from source control to an environment (typically development, staging, or live). These changes can be of any size, ranging from making small bug fixes and adding new features to deploying an entirely new website to a live environment.
For website development, it is a best practice to follow a deployment process flow and to use Git for version control. When a developer needs to work on a website, a common workflow will be to find the newest version of the website code in the version control system and clone that down locally to work on. With the latest version of the website code in hand and running locally, it's time to get to work on the changes that need to be made.
Once development is done, and the changes have been tested out locally, it's time to commit the changes, push it to source control and lastly deploy it to an environment.
While deployment happens between all environments, it's typically used in conjunction with where it's being pushed. So there's a good chance that you'll hear someone saying they're "deploying to live", meaning they are deploying changes that will be visible on the live website.
Deployment made easy with Umbraco Cloud
When you are using Umbraco Cloud you get the advantage of Umbraco Deploy, which is a deployment model that relies on Git and Kudu to move your changes from one environment to another.
In Umbraco Cloud we use a two-part deployment approach, which splits metadata and content, to make it as easy and flexible a process both for developers and content editors.
If you are interested in how deployment works with Umbraco Cloud you can see a short video tutorial below or go to our documentation on deployment for in-depth documentation on Umbraco Deploy.