Streamline Website Deployment with This Comprehensive Beginner's Guide to Automation
Table of contents
- Step 1) Get set up with an Azure DevOps account
- Step 2) Create a new repo
- Step 3) Create your index.html file within your new repo
- Step 4) Configure your pipeline with the initial setup
- Step 5) Finish configuring your new pipeline
- Step 6) Deploy your website. Automatically!
- Step 7) Bask in the glory of being a deployment master
- Summary
Learning how to automate your website deployment will save you tons of time and reduce the chances of making mistakes along the way. Automating web deployments is hands down one of the coolest things I have ever learned since becoming a software developer. Learn how to set up an Azure DevOps Pipeline by following this crash course guide. There are plenty of alternatives out there, one of the more popular ones being Octopus Deploy. Once you have the hang of things in one system it’s usually just a matter of learning the syntax and interface of another.
Disclosure: This post may contain affiliate links, meaning I get a commission if you decide to purchase through my links, at no cost to you. Please read my disclaimer for more information.
In my last blog, Deploying Your First Website | An Absolute Beginner’s Guide, I covered the steps necessary for deploying a super simple html file to a HostGator shared hosting environment. Today, we’re going to take what we did in that blog and pump it up with some DevOps steroids. So, let’s get started!
Assumptions
In this blog, I’m assuming a few things and I won’t be going into detail on some of the additional infrastructure needed to accomplish this task. Mainly, the topic of version control. Some day I’ll likely write a post about version control, but for now, I’ll put a pin in it. I will give a brief intro on how to do this all and you certainly don’t need to be a Git expert to accomplish this tutorial.
Step 1) Get set up with an Azure DevOps account
If you don’t already have an account you can get an Azure developer account by clicking this link.
When you first create a DevOps account it should ask you to create your first Organization. Name it anything you’d like, it’s not important at the moment. I’ll name mine NorthStarCode. After that choose a project name and choose whether you want the repository to be public or private. I typically set mine to private, unless I plan to offer up my code for other folks to see. After that just hit the + Create Project button and we’re off to the races!
Step 2) Create a new repo
Once your project is set up you should be seeing a screen like the one below:
This is the Summary page of the Azure DevOps dashboard. Our first step once we land on this page is to get a new Git repo set up and then to add a simple index.html file to it. Click on the “Repos” tab on the left-hand side of the dashboard to open it.
When you open the Repos tab for the first time the page can be a little overwhelming. Don’t worry about most of what’s at the top of the page. We’ll add our new file once we get our new repo set up and configured. Scroll to the bottom of the page and look for the following section.
There should be a section somewhere that says “Initialize main branch with a README or gitignore.” Go ahead and leave everything defaulted and click the Initialize button to generate a README file. Here is a good link if you’ve never seen a README file before.
Step 3) Create your index.html file within your new repo
At this point, we have most of the initial configuration complete to get our file added and ready to be deployed to our HostGator shared hosting environment. In the last step, you should have successfully created a README file and can now add your index.html file to your repo. Next to the name of your branch click on the three dots to view more options. Click Add a new folder, like the image below.
This will show yet another dialog box that asks you to specify your folder name and your new file name. Enter public_html as your folder name and then index.html as your file name and click “Create.” Creating a folder for your index.html file to live in is important for a later step when we configure the FTP upload.
I’m just going to use the same code I used from my last blog, but with a minor update to it so we can tell that the deployment worked. Here’s my index.html file code:
<!DOCTYPE html>
<html>
<head>
<title>My Automatically Deployed Website!</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style type="text/css">
#main {
background: green;
color: black;
}
</style>
</head>
<body>
<div>
<h1 id="main">Hello world!</h1>
<p>This is my first automated deployment!</p>
</div>
</body>
</html>
After you hit the add file button you should then see an editable window come up. Paste in the code you’d like for your file. Keep it simple though so we can make sure the deployment works. After you get it to work by all means start breaking things! That’s the best way to learn.
Anywho, once you have pasted in your code hit the “Commit” button to save the file and add it to your repo.
After you click “Commit” another side menu will pop up instructing you to add a comment. Put in whatever you want so you can review past changes more easily. Hit “Commit” once you enter a comment then leave the Branch name and the work items box as is.
Step 4) Configure your pipeline with the initial setup
With all of the branch setup out of the way, we can finally get to configuring our first pipeline. This is the meat and potatoes of the whole operation and is where the real power of these tools comes into play. Now that you’re finished setting up your index.html file click on the “Pipelines” tab on the left-hand side of the dashboard.
As soon as you open the default Pipelines window you should see a nice little graphic and some wording. Go ahead and click on the “Create Pipeline” button on the page.
I want to preface these next steps by saying that it can get a little overwhelming from here. BUT, don’t fret because I will walk you through all of the steps. So long as you’re following from start to finish you’ll get this to work. These tools are incredibly powerful. You could spend the better part of an entire career just getting to know how to use half of them.
Okay, enough rambling… After you’ve clicked on the “Create Pipeline” button you should see something like the following image. The first question is “Where is your code?” This is important, but we already know the answer because you just made it. Lucky for us it’s within Azure DevOps so it’s super easy to associate with our pipeline. Click on the “Azure Repos Git” option, here.
After clicking “Azure Repos Git” you’ll see the “Select a repository menu.” This will list all available repos within your DevOps dashboard. If this is brand new you should only see your freshly minted repo. For me, it is named “AutomatingDeployments.” Click on the name of your repo to move on to the next step.
Continuing with the steps in this section should lead you to the “Configure” page. In this menu, you’ll want to select the “Starter Pipeline” option. We want to keep this first pipeline dead simple so that you can get familiar with automating your deployments. Once you get the first run working you can try things out and tweak your pipeline all you want.
The “Review” step is going to show up next and, for me anyway, will likely seem like some crazy gibberish. Don’t get too hung up on this part as it’s not all that important to understand right now. I also am not by any means an expert on YAML files; I simply know why they’re helpful and use them myself in my projects. Long story short a *.yml file (pronounced yam-el) is a way to script your pipeline into text-based steps to make your pipelines portable and to be saved right inside of version control. This allows you to easily port a project and get it set up and running with the same settings in another environment. Furthermore, by adding the *.yml file to version control you can track changes to the file over time and rollback if you hose your pipeline.
Okay, with story time out of the way don’t worry about anything in this final “Review” step. Just hit the “Save” button. It might say “Save and run” by default but hit the down arrow to select Save instead. We’ll run the pipeline in just a moment.
You’ll quickly notice that whenever you make changes and go to save it will often show the side menu to add a commit message. This is important so that everything we do inside of our project can be “change tracked.” It’s very helpful when working on a team and you want to blame someone else for breaking stuff…Okay, sorry I got sidetracked, maybe that isn’t the main purpose. But, it is super important to keep track of changes to your project so you can easily “roll back” versions. You can also quickly pinpoint bugs that were introduced.
You can choose to enter a commit message or not, it doesn’t matter right now. Leave the radio button selected to “Commit directly to the main branch” and then hit “Save.”
Step 5) Finish configuring your new pipeline
This next step is where we will finish configuring our new pipeline and create the steps to connect to your remote host over FTP. This is the fun part, I promise!
The site then takes you back to the pipeline page after saving your new YAML file. From there click on the “Edit” button in the top right corner.
Once inside this menu, you’ll see your *.yml file hanging out next to your task options, just ignore it and don’t worry if it’s confusing. We’ll stick to clicking buttons and making things as easy as possible.
Next, on the right-hand side, you should see a “Tasks” menu. Inside the search bar type in “FTP” and you should see the “FTP upload” task shows up. Click on that to add it to your pipeline steps.
After you click on the FTP upload task it will show you the fields you need to fill in to configure your FTP connection. If you read my last blog, Deploying Your First Website | An Absolute Beginner’s Guide, you should already have that information. Simply enter the FTP details into this form. If the “Authentication Method” in the first field shows “FTP service connection” click on the dropdown arrow and select “Enter credentials” instead. I won’t get into the service connection steps in this tutorial because I want to keep it simple. I will likely make another post about it in the future, however.
Fill in the remaining fields with the same FTP connection details you used with FileZilla to manually upload your files. Be sure to add “ftp://” as a prefix to your FTP URL and then add “:21” as the port. So, your FTP URL should look something like this:
After you have that entered you need to enter the “Root folder” information and check the “File patterns” field to make sure it’s set to take everything from your repo and upload it to the remote host. The root folder should be public_html. This is why we made the index.html file from above specifically inside of a folder. It’s important to only upload the files you need and it’s easier to specify a folder that it lives in. (See the image below for clarification)
The “File patterns” field should say “**”. If it doesn’t then simply overwrite it so it does. This is a regex pattern telling it to include every file and every sub-directory and their files, and so on, from your local repo.
The “Remote directory” folder step is a really important detail. You may have to play around with this for a bit depending on the host you’re using. Ultimately, after playing around with it a bit, I just entered a forward slash “/” as the Remote directory and successfully uploaded my file to the root public_html folder out in my shared hosting environment.
The final *.yml file with my newly added FTP task looked a bit like the following image, for me.
There are only a few more steps and then I promise you the work, and reading, will be worth it! Before finishing adding the FTP upload step click on the “Advanced” options dropdown. In the advanced options check the “Clear remote directory contents” option as well as the “Trust server certificate” option. If you followed along in my other blog you may remember that the first time you tried connecting to the remote FTP server FileZilla showed a warning message about its certificate.
Checking the Trust server certificate will ensure that the build pipeline accepts this step and will not blow up as a result. The clear remote directory contents step is fairly intuitive in that it will delete everything from the remote folder before uploading your new files. This ensures that you are getting fresh, new files out to your server every time you deploy. (NOTE: Depending on how many permissions your hosting company gives you the clear directory contents option may or may not work. Just try it out and see if it does.)
OK, next simply hit the “Add” button at the bottom of the FTP form so we can finally try this out!
Potential Hiccup Warning
So, if you hit Save at the end of the last step and you notice a red squiggly line in the generated YAML file make sure that the newly added step was entered at the very bottom of that file. I’m not sure exactly why this is problematic sometimes, but I do know that it happens. Just cut it and paste it at the bottom and you should be good to go.
Hit the “Save” button in the top right of the window once you’ve completed the FTP step. Double check there are no squiggly red errors in your YAML file. It will prompt you to enter a message again, just leave the defaults and hit Save again. Click the back arrow in the top left to get back to our pipeline.
Step 6) Deploy your website. Automatically!
If you clicked the back button in the last step you should be brought to the Pipeline page of the pipeline we’ve been configuring. From there simply click on the “Run pipeline” button in the top right corner. Another side menu should show up with some additional options. Just leave everything as the default and click “Run” in the bottom right.
(In the following images you’ll notice I have DevOps in dark mode. I was being blinded so I changed it.)
After you hit Run you’ll be taken to the Build Results page. This page has a lot of information in it, but what we’re most interested in viewing, while we are doing a deployment, is at the very bottom under the “Jobs” section. Click on the word “Job” and it will open our build status page. From there we can watch the deployment happening and review errors, if they occur.
Hiccup Warning
When I tried running my new pipeline I got the following message returned as an error:
##[error]No hosted parallelism has been purchased or granted. To request a free parallelism grant, please fill out the following form aka.ms/azpipelines-parallelism-request
This was an annoying error, to say the least. After some research, I found out that the DevOps team and Microsoft had to do this because people were setting up these tools to do all sorts of nefarious nonsense and so they ruined it for everyone. Simply go to the link they are telling you to go to, fill out the form and in a few days you should be granted permission to run your pipeline without issues. It’s dumb and I hate that people ruin things for everyone else. This is literally why we can’t have nice things.
Step 7) Bask in the glory of being a deployment master
Provided everything worked accordingly to plan from the steps above then you should see a whole bunch of green checkmarks on the deployment status page. If you see all green checkmarks give yourself a huge pat on the back because not only did you successfully automate your website deployments, but you also just got yourself so many hours of wasted time back by not having to manually deploy your projects!
If you do not see all green checkmarks here take some time to analyze the errors, do some Googling and if anything please feel free to comment on this post and I’d be more than happy to help out. But, if you do see green checks go double check your shared hosting cPanel to verify if your new file shows up inside of your root public_html folder and then go to your website and hit Ctrl + F5 to do a full refresh of the page. If you see your new file show up you did it! You’ve now learned how to automatically deploy a website using Azure DevOps tools!
You can see my freshly created page that I deployed using a deployment pipeline by going to http://howtodeployawebsite.com and viewing my updated index.html file.
Summary
Alright, so if you haven’t figured it out by now I nerd out about this stuff, hardcore. My deployment learning journey looks a little bit like this:
I started out deploying my web projects directly through shared hosting tools. (Man that was awful)
I learned to deploy websites using FileZilla over FTP
I learned to use Beyond Compare to deploy websites (this gave me more insight into file changes and the ability to compare files more easily)
Finally, I learned the magic of using Azure DevOps deployment tools to automate deployments and I never looked back!
Honestly, the possibilities of these types of tools are limitless: You could use them to deploy websites to local network devices, run PowerShell scripts to automate boring tasks or make a stupid email sender to remind yourself to bring the garbage out. I mean seriously, endless possibilities with these tools. Now that you have a basic understanding of how to deploy a website using DevOps tools your life as a developer will truly never be the same.
I still remember the first time I successfully deployed a website this way I realized just how much faster I could make changes, build them and release them. All without needing to spend hours deploying things and potentially risking human error, ultimately leading to more time spent deploying. I now click two buttons, one to release my front-end application and another to release my API, then I walk away. The computer does the work for me. I value my time over everything else and this gave me back so much time.
These tools are also invaluable things to learn and understand as a professional developer and will most certainly help you advance your career in the future. Companies are jumping on board the DevOps bandwagon for numerous reasons. One main reason that developers love this, and subsequently the companies they work for, is because it reduces the human element. Humans aren’t built for repetitive tasks, computers are. We are prone to making mistakes during a complex deployment, it’s just a fact. So, leave it to the computer to follow a specified order of operations while you sit back and sip on that second cup of joe.
Post Summary, Summary
If you enjoyed this article or you have questions or comments I would love to hear from you. Be sure to like it, or react to it in some way. Sign up for my newsletter to get updates on my latest posts. If you’re feeling ambitious and you just loved what you learned from me I certainly wouldn’t be upset if you bought me a cup of coffee! Any sort of support helps me to keep producing content for you and sharing with you my journey as a software developer.
WARNING!
I do have an obligation to you in this post that I feel is important to disclose. What I have shown you in this post uses the FTP protocol. This protocol IS NOT SECURE and SHOULD NOT be used to transfer ANY sensitive material. If you are transferring files that contain password information or ANY sensitive material you MUST ensure that you are doing so over an encrypted connection. In my experience, most shared hosting providers do not offer secure FTP options. So, use FTP uploads to shared hosting at your own risk and please be mindful of the ethical responsibility you have when managing sensitive data.
Azure logo courtesy of logo wine
***Screenshots are taken from Azure DevOps. All images and copyright material therein are the property of Microsoft. I am showing this material simply for educational purposes and do not claim any creative content rights from those screenshots as my own. Thank you to Microsoft and the hardworking designers who made the content on their sight. I see you and I appreciate you.