What is Deployment?
Deployment in software and web development means to push 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 completed the new changes will be visible in the live environment.
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.
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 time plans 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.
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 amount 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.
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 meta data and content as these have different impacts on a new environment and need to be handled differently.
Meta data include 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.
Content such as text, images and videos are handled differently during deployment as they are less complicated to move between environments than meta data. 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 environments in Umbraco Cloud.
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 it also ensures that no one risks breaking something due to another user’s changes.
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.
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 meta data 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.