Challenge

Project 1 - V&V SW Analysis - I

Embedde offline batch 2

Practicing Continuous Integration and Continuous Delivery on AWS

Continuous integration :

Continuous integration (CI) is a software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. CI most often refers to the build or integration stage of the software release process and requires both an automation component (for example a CI or build service) and a cultural component (for example learning to integrate frequently). The key goals of CI are to find and address bugs more quickly, improve software quality, and reduce the time it takes to validate and release new software updates. Continuous integration focuses on smaller commits and smaller code changes to integrate. A developer commits code at regular intervals, at minimum once a day.

The developer pulls code from the code repository to ensure the code on the local host is merged before pushing to the build server. At this stage the build server runs the various tests and either accepts or rejects the code commit.

The basic challenges of implementing CI include more frequent commits to the common codebase, maintaining a single source code repository, automating builds, and automating testing. Additional challenges include testing in similar environments to production, providing visibility of the process to the team, and allowing developers to easily obtain any version of the application.

Continuous delivery and deployment :

Continuous delivery (CD) is a software development practice where code changes are automatically built, tested, and prepared for production release. It expands on continuous integration by deploying all code changes to a testing environment, a production environment, or both after the build stage has been completed. Continuous delivery can be fully automated with a workflow process or partially automated with manual steps at critical points. When continuous delivery is properly implemented, developers always have a deployment-ready build artifact that has passed through a standardized test process. With continuous deployment, revisions are deployed to a production environment automatically without explicit approval from a developer, making the entire software release process automated. This, in turn, allows for a continuous customer feedback loop early in the product lifecycle.

One misconception about continuous delivery is that it means every change committed is applied to production immediately after passing automated tests. However, the point of continuous delivery is not to apply every change to production immediately, but to ensure that every change is ready to go to production. Before deploying a change to production, you can implement a decision process to ensure that the production deployment is authorized and audited. This decision can be made by a person and then executed by the tooling. Using continuous delivery, the decision to go live becomes a business decision, not a technical one. The technical validation happens on every commit. Rolling out a change to production is not a disruptive event. Deployment doesn’t require the technical team to stop working on the next set of changes, and it doesn’t need a project plan, handover documentation, or a maintenance window. Deployment becomes a repeatable process that has been carried out and proven multiple times in testing environments

Benefits of continuous delivery :

  • Automate the software release process
  • Improve developer productivity
  • Improve code quality
  • Deliver updates faster

Testing stages in continuous integration and continuous delivery :

  • Setting up the source
  • Setting up and running builds
  • Building
  • Staging
  • Production

Deployment methods :

  • Deploy in place
    • All at once (in-place deployment) is a method you can use to roll out new application code to an existing fleet of servers. This method replaces all the code in one deployment action. It requires downtime because all servers in the fleet are updated at once. There is no need to update existing DNS records. In case of a failed deployment, the only way to restore operations is to redeploy the code on all servers again.
  • Rolling
    • With rolling deployment, the fleet is divided into portions so that all of the fleet isn’t upgraded at once. During the deployment process two software versions, new and old, are running on the same fleet. This method allows a zero-downtime update. If the deployment fails, only the updated portion of the fleet will be affected
  • Rolling with additional batch
    • AWS Elastic Beanstalk has followed the rolling deployment pattern with two deployment options, rolling and rolling with additional batch. These options allow the application to first scale up before taking servers out of service, preserving full capability during the deployment. AWS CodeDeploy accomplishes this pattern as a variation of an in-place deployment with patterns like OneAtATime and HalfAtATime.
  • Immutable
    • The immutable pattern specifies a deployment of application code by starting an entirely new set of servers with a new configuration or version of application code. This pattern leverages the cloud capability that new server resources are created with simple API calls.
  • Traffic splitting
  • Blue/Green
    • The blue/green deployment strategy is a type of immutable deployment which also requires creation of another environment. Once the new environment is up and passed all tests, traffic is shifted to this new deployment. Crucially the old environment, that is the “blue” environment, is kept idle in case a rollback is needed.
Project 1 :

Test plan for New mobile :

if (long_press power_button && phone_state OFF)
{
phone switched ON with the company logo at center;
}
elseif (press the power_button)
{
phone switched ON with apps icon present in the grid;
}
elseif (Phone is power_ON by product owner)
{
call_phone_icon should be first_icon AND Dictionary_icon will be second_icon at the bottom_bar of the screen;
}
elseif (call_phone_icon is clicked by product owner)
{
all contacts visible in chronological_order;
}
elseif (Dictionary_icon is clicked)
{
search_bar appear at the middle of the screen for word search;
}
elseif(long_press power_button AND phone_state OFF)
{
phone will be switched off with "Good bye" message;
}
elseif(it is a product_owner)
{
font_calibri and size_12;
}
elseif(customer)
{
UI is touch responsive;
}
else(customer)
{
touch_screen is sensitive and no hard_buttons;
}

Your portfolio, next

Ship work like this
in your own course.

Talk to a career counsellor

Free 20-minute call. We'll map the right course to where you want to work.

By submitting you agree to our Terms and Privacy Policy.