An Overview of the application that we will be deploying: 

My Shuttle is your one-stop solution for hassle-free transportation. This open-source, Java/JEE application streamlines bookings, simplifies driver management, and delivers an intuitive admin portal – all with the power of Linux, Apache, and MySQL. Say goodbye to booking delays and inefficient operations. My Shuttle empowers businesses to deliver exceptional customer experiences, optimize driver productivity, and boost efficiency across the board. 

Terraforming My Shuttle to Azure: Buckle Up for an IaC Adventure!

Get ready to ditch the manual configuration and embrace the power of Infrastructure as Code (IaC)! We’re taking My Shuttle to the cloud with Terraform, and you’re invited for the ride. 

Think of Terraform as your magic wand for building and managing cloud infrastructure. With a few lines of code, we’ll conjure up the perfect Azure environment for My Shuttle, complete with: 

• A dedicated resource group: Your own private cloud playground where My Shuttle can roam free. 
• A robust app service plan: The engine that powers My Shuttle’s web app, ensuring smooth performance for all riders and drivers. 
• A sleek Linux web app: My Shuttle’s digital home, ready to welcome users and manage bookings with grace. 
• A secure MySQL server: The brain behind My Shuttle, storing all your precious transportation data. 
• A dedicated database: Where all your booking details, driver information, and route optimization magic resides. 

But this isn’t just about code, it’s about empowering you to take control. With Terraform, you can: 

• Automate infrastructure provisioning: No more manual configuration headaches, just focus on building the best transportation app ever. 
• Version control your infrastructure: Just like your code, your cloud environment can evolve and be easily tracked. 
• Redeploy and scale with ease: Need more power? Terraform makes scaling My Shuttle to meet your needs a breeze. 
• Collaborate and share: Work with your team and share your infrastructure configurations seamlessly. 

So, are you ready to unleash the IaC magic? In the next few minutes of this blog, we’ll dive deep into the Terraform script and show you how to code My Shuttle’s Azure home. Get ready to learn, explore, and become an IaC wizard! 

Architecture Overview: 

My Shuttle Takes Flight with Azure: Decoding the Provider Block 

Remember that magical “cloud playground” we talked about? Time to build it! Now, we’re diving into the code that sets the stage for My Shuttle’s Azure adventure – the provider block. Think of it as the passport that grants access to all the amazing resources Azure has to offer. 
 

Let’s break down the code: 

• provider “azurerm”: This line tells Terraform to use the “azurerm” provider, our bridge to Azure’s vast infrastructure. 
• features { … }: This block allows us to customize how Terraform interacts with specific Azure resources. 
• resource_group { … }: We’re particularly interested in the “resource group” feature. Think of it as a gated community for your Azure resources. 
• prevent_deletion_if_contains_resources = false: This ensures that even if your cloud playground has some toys inside (resources), you can still demolish it if needed. 
• skip_provider_registration = true: This tells Terraform to skip the automatic registration process, as we’ll be providing our own credentials. 
• subscription_id, tenant_id, client_id, client_secret: These variables store your unique Azure credentials, the keys that unlock your cloud kingdom. 
  

My Shuttle Takes Root: Building the Foundation with a Resource Group! 

Remember that gated community we mentioned for My Shuttle’s Azure playground? Now, we’re laying the groundwork by building its first resident – the resource group! Think of it as a designated neighborhood where all the resources for your Java app will live happily ever after. 

Let’s decode the code: 

• resource “azurerm_resource_group” “rg_Java_appservices”: This line tells Terraform to create a specific type of resource (resource group) and gives it a unique name – “rg_Java_appservices”. 
• name = “rg_Java_appservices”: This makes the name official, ensuring everyone knows where to find My Shuttle’s resources in the vast Azure landscape. 
• location = “West Europe”: We’re choosing “West Europe” as our neighborhood, but you can pick any location that suits your needs. 
• tags = { Name = “MyshuttleJavaResourcegroup” }: Just like personalizing your house with a nameplate, we’re giving the resource group a tag to identify it as My Shuttle’s dedicated Java playground. 

My Shuttle Gets its Engine Running: Introducing the Azure App Service Plan! 

Remember that dedicated neighborhood we built for My Shuttle? Now, it’s time to give it some power! We’re now introducing the Azure App Service Plan, the engine that will keep My Shuttle’s Java app running smoothly. Think of it as a high-tech power plant that fuels the entire operation. 

Let’s dissect the code: 

• resource “azurerm_app_service_plan” “java_splan”: This line tells Terraform to create a specific type of resource – an app service plan – and gives it a fitting name, “java_splan”. 
• location = azurerm_resource_group.rg_Java_appservices.location: We’re placing the app service plan within the same neighborhood we built earlier, ensuring all the resources are neatly organized. 
• resource_group_name = azurerm_resource_group.rg_Java_appservices.name: We tell Terraform exactly which neighborhood – “rg_Java_appservices” – to install the power plant in. 
• reserved = true: We choose a “reserved” plan, guaranteeing consistent performance for My Shuttle’s app, even during peak hours. 
• kind = “linux”: Since My Shuttle is a Java app, we select the “linux” option to ensure the engine is compatible. 

Now, let’s delve into the sku block: 

• tier = “Basic”: We start with a “Basic” tier to keep things cost-effective, but can easily upgrade later as My Shuttle takes off. 
• size = “B1”: We choose the “B1” size, offering enough power for our current needs. 
• capacity = 1: We allocate one app service instance for now, but can easily scale up as the demand for My Shuttle grows. 

My Shuttle Finds its Data Home: MySQL Server and Database Take Flight! 

Remember that high-tech power plant we built for My Shuttle’s Java app? Now, it needs a secure and reliable data haven. Enter the Azure MySQL Server and Database, the brain trust where My Shuttle will store all its vital information – bookings, drivers, routes, and more. Think of it as a fortified vault for your digital treasure. 

Server: 

Database: 

 Let’s break down the code: 

• resource “azurerm_mysql_server” “devopsothon12345”: We’re creating a dedicated MySQL server with a fitting name – “devopsothon12345”. 
• location, resource_group_name: We place it within the same neighborhood as the app service plan, ensuring efficient data management. 

• administrator_login, administrator_login_password: We secure the server with a strong login and password stored in variables (don’t share them!). 
• sku_name, storage_mb, version: We choose a “GP_Gen5_2” tier with 5120 MB storage and a reliable “5.7” version. 
• auto_grow_enabled, backup_retention_days: We enable automatic storage growth and keep backups for a week, ensuring data safety. 
• infrastructure_encryption, public_network_access, ssl_enforcement: We prioritize security with encryption, limited public access, and enforced SSL for secure connections. 

Moving on to the resource “azurerm_mysql_database” “alm” block: 

• name = “alm”: We create a database named “alm” to store My Shuttle’s valuable data. 
• resource_group_name, server_name, charset, collation: We link it to the server, define the character set (“latin1”), and set the collation for efficient data handling. 
• depends_on: We ensure the database is created only after the server is up and running. 

Finally, the resource “azurerm_mysql_firewall_rule” “FWR1” block: 

• name = “officeClientIPAddress”: We create a firewall rule named “officeClientIPAddress” to control access. 
• server_name, start_ip_address, end_ip_address: We define the server to protect and limit access to only a specific IP address (“106.51.65.168”) for additional security. 
   

My Shuttle Takes Flight with Insights: Monitoring for a Smooth Ride 

So now that we have built a powerful engine and secure data haven for My Shuttle, it’s time to equip it with eyes and ears! Enter Azure Application Insights, the eagle-eyed guardian that will monitor My Shuttle’s performance and health. Think of it as a control panel for your transportation ecosystem, providing valuable insights to keep everything running smoothly. 

Let’s decode the code: 

• resource “azurerm_application_insights” “Insights11”: We’re creating an Application Insights resource with a fitting name – “Insights11”. 
• location, resource_group_name: We place it within the same neighborhood as the app and data, ensuring efficient monitoring. 

• application_type = “web”: We tell Insights11 that it’s a web application it’s watching over. 
• depends_on = [azurerm_app_service_plan.java_splan]: We ensure Insights11 is activated only after the app service plan is up and running. 

My Shuttle Takes Off: Launching the Java Web App! 

Remember that powerful engine and secure data haven we built for My Shuttle? Time to ignite the engines and launch the web app! Now, we deploy the Azure Linux Web App (Java), the brain and brawn that will power My Shuttle’s booking experience. Think of it as the control tower for your transportation journey, guiding users with ease and efficiency. 

Let’s dissect the code: 

• resource “azurerm_linux_web_app” “new_Tommy_app”: We create a web app with a fitting name – “DevopsAthonMyshuttledev”. 
• location, resource_group_name: We place it within the same neighborhood as the rest of My Shuttle’s resources for seamless integration. 
• service_plan_id: We link it to the powerful app service plan we built earlier, ensuring smooth operation. 
• site_config { … }: This block defines the web app’s inner workings: 
• always_on = true: We keep My Shuttle’s engines humming 24/7, ready for riders anytime. 
• java_server, java_server_version, java_version: We specify Tomcat 9.0 as the server and Java 8 as the runtime environment, perfectly suited for our Java app. 
• connection_string { … }: This crucial block establishes the connection to My Shuttle’s data haven: 
• name = “MYSQLCONNSTR_MyShuttleDb”: We give it a memorable name for easy reference. 
• type = “MySql” and value: We define the connection details for our Azure MySQL server and database, ensuring secure access to user data. 
• app_settings { … }: These settings fine-tune My Shuttle’s performance: 
• WEBSITE_NODE_DEFAULT_VERSION: We set the Node.js version for any additional dependencies. 
• APPINSIGHTS_INSTRUMENTATIONKEY & APPLICATIONINSIGHTS_CONNECTION_STRING: We integrate Application Insights for real-time performance monitoring. 
• ApplicationInsightsAgent_EXTENSION_VERSION: We configure the Application Insights agent version. 

• depends_on = [azurerm_mysql_database.alm]: We ensure the web app only launches after the database is ready. 

My Shuttle Takes Off: Fueling the Journey with Variables! 

Remember the intricate blueprints for My Shuttle’s Azure home? Those detailed plans, filled with Terraform scripts and configurations, need some key ingredients to come to life: variables! Think of them as the fuel that powers My Shuttle’s journey to the cloud. 

Here’s how these variables play a crucial role: 

• Subscription ID: This unique identifier acts like My Shuttle’s passport to the Azure universe, unlocking access to all its resources. (Variable: subscription_id) 
• Client ID and Secret: These are the secret keys that grant My Shuttle’s automated pilot, Terraform, the authority to manage Azure resources on your behalf. Think of them as the pilot’s license and access codes. (Variables: client_id and client_secret) 
• Tenant ID: This identifies the specific Azure cloud My Shuttle calls home, ensuring it lands in the right airspace. (Variable: tenant_id) 
• Administrator Login and Password: These are the captain’s credentials, allowing My Shuttle to securely configure and manage its Azure infrastructure. Think of them as the launch codes for the cloud. (Variables: administrator_login and administrator_login_password) 

My Shuttle Takes Flight: Your Guide to Liftoff! 

We’ve meticulously crafted My Shuttle’s Azure home, layer by layer, brick by Terraform code. Now, it’s time to ignite the engines and take off! But before we blast off, let’s prepare for a smooth journey: 

1. Set the Course: 

• • Gather your secret weapons – subscription_id, tenant_id, client_id, and client_secret – and store them securely as variables in your Terraform script. Think of them as the keys to your Azure kingdom. 
• • Double-check the code to ensure everything is configured to your liking. This is your chance to personalize My Shuttle’s Azure environment before launch. 

2. Initialize and Prepare for Launch: 

• • Open your terminal, navigate to your project directory, and run terraform init. This prepares your spaceship – downloading the necessary Azure modules and ensuring everything is ready for liftoff. 
• • Now, hold onto your hats and type terraform apply. This command initiates the launch sequence, deploying all the resources we’ve built for My Shuttle on Azure. Watch in awe as your resource group, app service plan, database, and web app come to life! 

3. Sit Back and Enjoy the Ride: 

Once Terraform finishes its magic, My Shuttle’s Azure home will be ready to take flight. You can now: 

• • Access your web app and start building the user interface, adding features, and making My Shuttle your own. 
• • Monitor performance and user behavior with Application Insights to keep your transportation engine running smoothly. 
• • Scale your infrastructure up or down as needed to accommodate My Shuttle’s growing popularity. 

 
So, now as we are done with the infrastructure it’s time to integrate it and to build and deploy our application with the help of AWS Codepipeline. So, let’s begin with it. 

My Shuttle Soars Beyond the Clouds: CI/CD with AWS CodePipeline! 

We’ve built My Shuttle’s Azure home, but it’s just a hangar without a plane. Now, it’s time to fuel the engines of CI/CD with AWS CodePipeline and launch My Shuttle into the cloud stratosphere! 

Think of CodePipeline as our mission control center, orchestrating every step from code changes to a fully operational My Shuttle on Azure. Let’s break down the workflow: 

1. Version Control: My Shuttle’s code, both Terraform scripts and Java application files, reside safely in a version control system like Git. Every change is tracked, ensuring smooth rollbacks and easy collaboration. 

2. CI Build: AWS DevOps keeps a watchful eye on the Git repository. Whenever new code is pushed, it triggers a CI build. Imagine this as our engineers analyzing the changes and preparing My Shuttle for launch. 

3. Terraform Plan: During the CI build, CodePipeline runs terraform plan. This meticulous planner examines the changes and generates a detailed blueprint for updating My Shuttle’s Azure infrastructure. Think of it as a flight plan for our cloud journey. 

4. Infrastructure Deployment: If the plan is approved, CodePipeline unleashes the power of terraform apply. This command activates the blueprint, provisioning and configuring My Shuttle’s Azure resources – the runway, the control tower, everything! 

5. Application Build: While the infrastructure takes shape, Maven gets to work building the Java application. It meticulously compiles the code into a WAR file, the heart and soul of My Shuttle’s functionality. 

6. Artifact Storage: Just like a careful pilot storing charts and maps, CodePipeline securely stores all the artifacts – the WAR file, Terraform scripts, and any other essential files – for future reference. 

7. CD Deployment: Now, the real magic happens. CodePipeline executes the CD deployment, which involves pushing the WAR file to My Shuttle’s running Azure environment and configuring it for optimal performance. Think of this as our engineers fine-tuning the engines and instruments before takeoff. 

8. Security Scanning: But safety is our top priority! CodeGuru scans the deployed application for potential security vulnerabilities, ensuring My Shuttle’s passengers and data are always protected. 

This CI/CD pipeline is the fuel that keeps My Shuttle soaring. It automates and streamlines the entire process from code changes to a fully functional Azure application. 

In the next few minutes, we’ll dive deeper into the specific steps of the CI/CD pipeline and explore how to customize it for My Shuttle’s unique needs. 

AWS CodeCommit: A Secure Hangar for Our Cloud Journey! 

Remember that sprawling repository of Terraform code and Java application files? We need a safe haven for this precious cargo, and that’s where AWS CodeCommit comes in! Think of it as My Shuttle’s private hangar in the cloud, securely storing all the blueprints and tools needed to keep it soaring. 
 

 Here’s why CodeCommit is the perfect fit for My Shuttle: 

• Secure Storage: CodeCommit uses industry-leading encryption and access controls to keep our code safe from prying eyes. No unauthorized takeoffs allowed! 
• Version Control: Every change, every tweak to My Shuttle’s code is meticulously tracked and stored. Need to revert to a previous version? CodeCommit is your time machine. 
• Collaboration: Multiple engineers can work on My Shuttle’s code simultaneously, all within the secure confines of CodeCommit. Teamwork makes the cloud dream work! 
• Integration with CI/CD: CodeCommit seamlessly integrates with AWS CodePipeline, our mission control center for CI/CD. Changes in the repository automatically trigger the build and deployment process, keeping My Shuttle fueled for its next flight. 
• Cost-Effective: CodeCommit offers a free tier for small projects, making it a budget-friendly choice for My Shuttle’s early stages. As our needs grow, CodeCommit scales with us, offering flexible pricing options. 

Hosting our code in CodeCommit provides a solid foundation for My Shuttle’s development. It ensures the code is safe, accessible, and ready to be seamlessly integrated into our CI/CD pipeline. Think of it as the sturdy hangar doors that protect our precious aircraft before it takes to the skies. 

AWS CodeBuild: Fueling Our CI/CD Engine! 

Remember that meticulous plan for My Shuttle’s infrastructure and application? Now, we need a powerful engine to execute it! Enter AWS CodeBuild, our CI/CD fuel injector, responsible for transforming code changes into a fully operational cloud journey. 

Think of CodeBuild as our automated pit crew, taking the Terraform scripts and Java application code from CodeCommit, building and testing everything, and then delivering the ready-to-fly My Shuttle to our Azure hangar. 
 

 

Here’s how CodeBuild powers My Shuttle’s CI/CD pipeline: 

• Automated Builds: Every push to our CodeCommit repository triggers a CodeBuild “build.” Imagine robots diligently running terraform plan and terraform apply, ensuring the infrastructure is ready for liftoff. 
• Customizable Build Environments: We can configure CodeBuild to use specific operating systems, programming languages, and tools, perfectly tailored to My Shuttle’s needs. No one-size-fits-all engine here! 
• Scalability: CodeBuild scales with our project, automatically spinning up additional build instances to keep My Shuttle’s engines running smoothly, even with frequent code changes. 
• Integration with Other AWS Services: CodeBuild seamlessly integrates with CodePipeline, our mission control center, and other AWS services like S3 for artifact storage, making My Shuttle’s CI/CD journey seamless. 
   
   

Now the steps to build our application: 
It’s time to transform it into a soaring reality with AWS CodeBuild! Think of it as our cloud garage, where code gets transformed into a fully functional app. Let’s dive into the steps (Create a build project): 

1. Project Configuration: 

• Name it! Your project deserves a fitting title, like “MyShuttle-Java-App”. 

• Additional polish: Add a description, build badge, or tags to personalize your garage. 

2. Source: 

• CodeCommit connection: Select your CodeCommit repository, where the Terraform scripts and Java code reside. Think of it as grabbing the blueprints and tools from the shelves. 

3. Environment: 

• Image choice: Choose a pre-built image (managed) or a custom Docker image (customized) for your build process. Think of it as picking the perfect engine for My Shuttle. 
• Operating system: Select the OS that plays nice with your code, like Linux for Java goodness. 

4. Service Role: 

• New or existing: Create a new service role with the necessary permissions for CodeBuild to access resources, or choose an existing one. Think of it as giving your garage keys to a trusted mechanic. 

5. Buildspec: 

• YAML magic: CodeBuild loves instructions in YAML. Upload a buildspec file with commands for running Terraform, Maven, and anything else needed to build My Shuttle. Think of it as the detailed instructions for assembling your cloud masterpiece. 

6. Artifacts: 

• S3 storage: Choose Amazon S3 as the artifact type, and CodeBuild will securely store the built My Shuttle app (WAR file) in your designated bucket. Think of it as parking your gleaming app in a secure cloud garage compartment. 

With these steps, you’ve prepped your CodeBuild garage for action! 

Now let’s dive deeper into crafting the perfect buildspec, ensuring My Shuttle gets assembled seamlessly and efficiently. 
 
Unveiling the Buildspec Magic! 

Let’s take a peek at the buildspec file, the magic script that guides CodeBuild in assembling My Shuttle! 

 Phase by Phase: 

• Install: It’s all about setting the stage. This phase updates the package list and installs Java 11, the foundation for building our app. 
• Pre-build: Maven, the master builder, arrives! This phase installs Maven, ensuring it’s ready to work its magic on our Java code. 
• Build: The engines roar! This phase invokes Maven with the –Dmaven.test.skip=true flag to prioritize building the app without running tests, saving precious time. 
• Post-build: Time for polish and security! This phase: 

• • Prints the current directory to confirm everything is in place. 
• • Installs jq, a helpful JSON processor. 
• • Zips the built application into myshuttledev.zip for easy deployment. 
• • Installs the AWS CLI for interacting with our cloud resources. 
• • Runs the run_codeguru_security.sh script for security scanning. 

Artifacts: CodeBuild’s treasures! This section defines what to store after the build: 

• • target/myshuttledev.war: The built app, ready to take flight! 
• • appspec.yml: Configuration file for deployment. 
• • Various scripts and Terraform files: Our cloud blueprints and tools. 
• • CreateMYSQLDB.sql: Script to create the database schema (if needed). 

This buildspec is the secret sauce that brings My Shuttle to life! It ensures everything is installed, built, packaged, and secured, preparing it for deployment to the Azure cloud. 
 
Now it’s time to unveil the appspec.yml, the secret map guiding My Shuttle’s deployment on our Azure home! Think of it as the flight plan for our cloud journey. 

Let’s dissect its key elements: 

• Version: Currently at 0.0, ready for future updates as My Shuttle evolves. 
• OS: It specifies Linux as the operating system where our app will reside. 
• Files: This defines what gets deployed: 
  • • Everything from the root directory (/) gets copied to /opt/codedeploy-agent/, ensuring the deployment agent has everything it needs. 
  • • The built app, target/myshuttledev.war, lands in /home/ubuntu/MyShuttle/, its designated landing pad. 
• Hooks: These are like automated pit stops during deployment, triggering specific scripts at crucial moments. 
• BeforeInstall: Just before installing the app, /Scripts/Azcli.bash script kicks in, likely setting up the Azure CLI tools needed for infrastructure adjustments. 
• AfterInstall: Once the app is installed, /Infra/Infra.bash script takes over, possibly handling additional Azure infrastructure tasks. 

• ApplicationStart: When it’s time for liftoff, /Scripts/deploy.bash takes the stage, likely starting the My Shuttle application server and configuring it for flight. 

This appspec.yml is the brain behind My Shuttle’s deployment! It tells CodeDeploy what to copy, when to run scripts, and ultimately, how to launch our app on Azure. 

AWS CodeDeploy: Orchestrating the Takeoff! 

Now, it’s time to fuel the deployment engines with AWS CodeDeploy! Think of it as our mission control center for orchestrating My Shuttle’s smooth launch onto Azure. 

CodeDeploy takes the baton from CodeBuild, receiving the built app and appspec.yml from the cloud garage. It then takes care of the rest, guiding My Shuttle through the following stages: 

1. Download and Extract: CodeDeploy downloads the app and appspec.yml to the designated location on our Azure instance. Imagine it carefully unpacking the app and its instructions onto the launchpad. 

2. Install and Configure: Guided by the appspec.yml, CodeDeploy executes the specified scripts – like /Infra/Infra.bash – to configure the Azure environment and prepare for liftoff. Think of it as our engineers making sure everything is set up and ready to go. 

3. Start the App: Finally, CodeDeploy triggers the deploy.bash script, which activates the My Shuttle application server and puts it into operation. Imagine the engines roaring to life, propelling My Shuttle towards its cloud destination! 

4. Monitor and Rollback (if needed): CodeDeploy keeps a watchful eye on My Shuttle’s health, ensuring it’s running smoothly. If any issues arise, it can even automatically roll back to a previous version, making sure our journey is safe and reliable. 

CodeDeploy offers several advantages for My Shuttle: 

• Ease of use: It simplifies deployments with a straightforward configuration and automated execution. 
• Scalability: It can handle frequent deployments and scale to accommodate My Shuttle’s future growth. 
• Integration with other AWS services: It seamlessly integrates with CodeBuild and other services, creating a powerful CI/CD pipeline. 
• Security: It offers features like access control and encryption to keep My Shuttle and its data safe. 

 
Now the steps to Deploy our application: 

It’s time to ditch the launchpad and soar into the cloud with the power of AWS CodeDeploy! Think of it as our Mission Control, meticulously guiding My Shuttle through a smooth and efficient deployment. 

Here’s how we’ll launch My Shuttle to new heights: 

1. Creating the Deployment Application: 

 

• Name it: Give your application a fitting title, like “MyShuttle-Java-App.” 

• Choose your platform: We’re aiming for the Azure clouds, so select “EC2 On-premise” as our compute platform. 

2. Crafting the Deployment Group: 
 

 

• Name it: Give your deployment group a unique identifier, like “MyShuttle-Prod-Deployment.” 
• Service role: Assign a service role, granting CodeDeploy access to necessary resources. Think of it as the pilot’s license for accessing Azure. 
• Deployment type: Choose your flight path: 
• In-place: Update existing instances one by one, minimizing downtime but potentially causing brief interruptions. 
• Blue/green: Spin up new instances, deploy the app to them, and smoothly switch traffic, ensuring zero downtime for My Shuttle users. 
• Deployment configuration: Choose how fast you want to rocket towards success! CodeDeployDefault.AllAtOnce is a good starting point for rapid deployment. 
• Load balancer: Select a load balancer to distribute traffic seamlessly during the deployment. Imagine a skilled air traffic controller ensuring smooth transitions. 

3. Creating the Deployment: 
 

 

• Deployment group: Choose the group you just created, “MyShuttle-Prod-Deployment.” 
• Revision type: My Shuttle’s app is in S3, so select “My application is stored in Amazon S3.” 
• Revision location: Copy-paste the S3 bucket address where your WAR file resides. Think of it as handing the launch codes to CodeDeploy. 
• Deployment description: Add a brief note about the deployment, like “MyShuttle v2.0 launch.” 
• Additional settings: Fine-tune the flight parameters: 
• ApplicationStop lifecycle event failure: Choose what happens if the app fails to stop on an instance. 
• Content options: Decide what to do if existing files on the instance clash with the new app version. 

Liftoff! 

Click “Create deployment,” and watch CodeDeploy work its magic! It will download the app, configure the Azure environment, and seamlessly launch My Shuttle into the cloud. 
 

We’ve meticulously crafted its infrastructure, built its Java engine, and now, it’s time to launch it into the stratosphere with the power of CI/CD.  
It’s a symphony of collaboration, where changes in our code trigger a beautiful dance of builds, tests, deployments, and security checks, all ensuring My Shuttle’s journey is smooth and efficient. 

Here’s how CI/CD fuels My Shuttle’s flight: 

• CodeCommit: Our secure hangar, where our Java code and Terraform scripts reside, waiting to be transformed. 
• CodeBuild: Our tireless garage, automatically building and testing My Shuttle with every code change. Think of it as a team of skilled mechanics turning blueprints into a gleaming app. 
• CodePipeline: Our mission control, orchestrating the entire CI/CD process, from code changes to deployment on Azure. Imagine a meticulous air traffic controller guiding My Shuttle through every step. 
• AWS DevOps: The masterminds behind the scenes, providing the tools and services that make CI/CD flow seamlessly. Think of them as the architects of our cloud journey. 

 
Buckle up, fellow passengers! My Shuttle is ready to soar with the power of CI/CD, and we’re on a journey to revolutionize transportation one code change at a time. 

Azure and AWS Join Hands for a Cloud Revolution! 

We’ve meticulously built its infrastructure, crafted its Java engine, and launched it into the stratosphere with CI/CD. But wait, there’s a twist! 

In a stunning turn of events, Azure and AWS, the cloud giants, have finally shaken hands! This isn’t just a diplomatic gesture; it’s a game-changer for My Shuttle and the entire cloud landscape. 

My Shuttle, built on AWS CodeBuild and CodeDeploy, seamlessly interacts with its Azure infrastructure provisioned by Terraform. The code changes flow effortlessly, the deployments happen across both clouds, and My Shuttle soars through the hybrid sky, fueled by the combined power of both platforms. 

 
Happy Cloud Flying!