Serverless website deployment 100% automated in multiple environments (Test, QA and Production) using Azure DevOps Repos and Pipelines (CI/CD).
In another project based on a real-world scenario, I worked as a Cloud Engineer using DevOps, where I deployed a serverless website in a 100% automated way using Azure DevOps Repos and Azure DevOps Pipelines resources.
Azure DevOps Organization and a new project have been created. The Azure DevOps Repos stored the website files, and the CI/CD Pipelines automated the entire website deployment process in 3 different environments (Test, QA, and Production).
Before I start how this project was completed I will note that I had to submit an Azure DevOps Parallelism Request in order for this project to even be achievable. If you are interested in this you can find the request here: Azure DevOps Parallelism Request (office.com)
Here is the 3 step process I followed to accomplish this task:
Step 1: Create a storage account for each environment; Testing, Q&A, and Production.
Step 2: Configure the Repository and Pipelines
Step 3: Test the environments, make changes to environments, and verify with another test that changes were correctly made to the 3 environments.
Step 1: Creating the Storage Accounts for environments.
In the Azure Home Portal simply search for Storage Accounts and then click on Create. Name the Storage Account for the environment you want it to represent. I made 3 separate accounts and named them; tcbrk1tst, tcbrk1qa, and tcbrk1prd.
Basically I provided a name, Resource Group and region and left everything else as the default.
Now, I needed to enable a static website for each environment Storage Account.
Click on your Storage Account > Scroll down to the “Data Management” pane and select ‘Static website’. From here, I simply “Enabled” the static website setting and provided an “Index document name” which for me was ‘index.html’.
I was provided a Primary Endpoint (web URL) for each environment. These endpoints eventually will take us to their respective Web Pages in any web browser!
You can copy/paste these URLs into a notepad for easier access, but you can get the URLs anytime you want from your Storage Accounts.
Step 2: ***Before proceeding ensure that your request for Azure Devops Parallelism was approved. Microsoft sent me my approval email within 48 hours***
In the Azure home portal you can search for “Azure Devops Organizations” and click on the option that pops up. From here, you will click on your organization (should have been created prior to submitting request for Parallelism) and create a new project.
I simply named my project “website01” and made it a private project.
From here, the Parallelism should automatically attach itself to the project. I ran into an issue where it didn’t and had to scrap the entire project (deleted it) and started over. It was a painful and time consuming resolution.
Now that my Project is created I clicked on Repos > Files and “Generate Git Credentials”. Copy that password and pasted it to a notepad for future use (in GitBash).
I then opened GitBash and Changed Directories to my Desktop/Azure/ folder and ran the “Git clone https://github.com/thecloudbootcamp/azuredevops.git” command.
This command provides the information needed for our static websites, (source codes, etc). To see that the command ran successfully you can run “ls -ltr” and see the directory (azuredevops) and associated files were added to your computer.
Next, I needed to run the “git remote remove origin” command to remove any residual files from previous projects or left over from the source code provided.
Now I could run, “git remote add origin https://thecloudbootcamp@dev.azure.com/thecloudbootcamp/website01/_git/website01”. You should be prompted for a password, I mentioned earlier we would need it so I copied and pasted from notepad into GitBash (***NOTE: When I pasted the password into GitBash there was no indication anything was added to the prompt***) I just hit enter and it ran. This command simply uploaded the folders/file/information to my Repository > Files.
Now that my Repository is created and I was able to comfirm our Files were uploaded successfully with the “git remote add origin https://thecloudbootcamp@dev.azure.com/thecloudbootcamp/website01/_git/website01” command it’s time to build my Pipeline.
Step 2 (cont): In my website01 project I clicked on the Pipelines tab in the left side pane and selected Pipelines again, Create Pipeline.
I used the classic Editor. This is no longer a default option. If you would like to enable the classic editor option follow the steps mentioned in this article: How to enable the classic build and release pipelines in Azure DevOps | by Francisco Güemes | Medium
Using the Classic Editor I kept the defaults and continued. I started with an Empty Job as well.
Clicked on “Agent Job 1” and then the “+” to add another task.
Searched for “Archive Files” and added that to the tasks.
I named Archive File “Zip files” and in the Root folder or file to archive section I browsed to our project Repository and selected my “File” folder. It has to be the entire “Files” folder!!!
Everything else for this task was left as default!
I then added another new task, “Publish Build Artifacts”. I changed the display name to “Artifacts Publish” and left defaults everywhere else.
I then saved (Not “Save and queue!). Click on Triggers and Click on “Enable Continuous Integration” option. Save again!
Now! I needed to create a new pipeline for Continuous Deployment. We already have the CI of CI/CD from the previous step. Now lets complete the CD portion.
Click on Pipelines on the left hand pane > Releases > New Pipeline.
Select “Empty Job” again.
Click on Add an Artifact. Leave Project as default (website01 for me) and then in the “Source (build pipeline)” drop down menu select the only option that is there (website01-CI for me). Notice the CI? Continuous Integration… Anyway, Select Add after that.
Click on the Lightning Bolt Icon at the top right corner of the Artifact that we just created and Enable “Continuous Deployment”. Ahhhh full circle!
Now, I need create the testing, Q&A, and Production Stages in this Release Pipeline. I clicked on Stage 1 and renamed it “Testing”. Then, I clicked on ‘1 job, 0 task’. Clicked on “Agent Job” and clicked on “+” to create a new task.
search for Extract Files and add it. Changed the Display name to “Extract files from website”. For Archive File Patterns and Destination folder I changed them what I needed to from some of the documentation given to me for this project.
I then added a new task, “Azure CLI”. Change display name to “Upload files to Azure Blob” and for the “Azure Resource Manager connection” I wanted to use my Azure Subscription that was also used by my created Storage Accounts in Step 1. You will need to provide username/password for this step to complete (***Note: I didn’t have to signin to my Azure account. It simply connected and scoped itself out so I’m not entirely sure?***).
Change Script Type to “Shell”, Script Location to “Inline Script”, and Inline scripts needs to be: “az storage blob upload-batch — account-name tcbrk1tst — destination “\$web” — source ./files — overwrite”. These names will be slightly changed for Testing, Q&A, and Production Environments. You need to update the “tcbrk1tst” portion for your environment naming scheme.
Also note: “ — overwrite” is necessary here for changes to relfect!
Rename the Pipeline so you know what it is for. I named mine website01-CD and click on the save button, and ok to save.
Now, I just cloned (clone button) the Testing Stage and renamed it “Q&A”.
The only thing I needed to change was the Inline Script in the ‘Upload files to Azure Blob’ task to, “az storage blob upload-batch — account-name tcbrk1qa — destination “\$web” — source ./files — overwrite” and click save!
Once back to my Release Pipeline page Clone the “Q&A” stage and rename it “Production”. I then clicked on Jobs within the stage to edit the ‘Upload files to Azure Blob’ task. Inline Script was changed to, “az storage blob upload-batch — account-name tcbrk1prd — destination “\$web” — source ./files — overwrite” and click save and then go back to Pipeline page.
From here I clicked on Production Stage Lightning Bolt icon on the Left side of the Stage. From here, I enabled “Pre-Deployment Approval”. I then added my Azure Account Email Address to require me to approve changes to testing/q&a before being uploaded to Production Environment.
Step 3: Testing, verifying my web URLs work, making a change to our URLs index.html files, run the pipeline again, verify changes to index.html files were successful for each environment.
Click on Pipelines > Pipelines > select the Pipeline I’m working with (website01-CI) > Click on Run Pipeline.
Click on Agent Job 1 and you can keep up with the processes being performed.
Once the “Post-job: Checkout website01@…” is finished you can go back to the pipeline release and check the status of the run. If you click on a stage in progress you can see the status of that run in that stage.
Once each stage is completed you can grab the URL associated with that environment and test.
Now, Once all three of your stages have successfully completed within the “Run” we can try to make a change to our static websites (environments).
Lets say I want to change “Congratulations!” to “Good Job!”.
***Side Note: the file I needed to change for this was in Portuguese and I do not speak/read/or write Portugues. Thank goodness for online translators!***
In GitBash in the correct directory (holding your index.html file and folder). type in “vi index.html”.
Using the arrow keys, find “Congratulations!” and get your cursor just in front of it and hit backspace to delete “Congratulations” (you can leave the “!”).
To edit this text press your “i” key and then type in “Good Job!”. To exit editing the code pres “esc” key.
To save changes here type in “:x” and hit enter.
Run the “git add index.html” command
Run “git config — global user.email “<enter email associated with account>”
Run “git commit -m “index.html” change”
Run “git push -u origin — all”
Now, We are going to go back to our Pipelines and you should see that another Release/Run was started. Click on the ‘Release’ and you can track the progress once again.
Once all stages are completed you approved the change to Production and it completes you can test your website URLs again.
As we can see, “Good Job!” has replaced “Congratulations!” in our Production Environment.
I have successfully created, tested, changed, and verified changes were made in my 100% automated serverless website deployments using Azure DevOps Repos and Pipelines (CI/CD).
Once again, Thank you for taking your time to read my process on how this Real World hands on project was accomplished!
-Ryan
