Software Engineering - chp8- deployment

MedTech
Chapter 8 – Deployment
Deployment Process, Best Pratices, DevOps
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
MedTech – Mediterranean Institute of Technology
CS321-Software Engineering
MedTech

MedTech
INTRODUCTION TO DEPLOYMENT
Deployment
Dr. Lilia SFAXI
Slide 2

MedTech
Deployment Phase
• One of the biggest application lifecycle management challenges
• Deployment
• All the activities that make a software system available for use
• Activity responsible for movement of approved releases to test and
production environment
• Release
• A collection of hardware, software, documentation, processes or other
components required to implement one or more approved changes to IT
services
• The contents of each release are managed, tested and deployed as a single
entity
• Release and Deployment Management
• Process responsible for planning, scheduling and controlling the movement
of releases to test and production environments
Dr. Lilia SFAXI
Slide 3
Deployment

MedTech
Objectives
• Efficiently build, install, test and deploy releases to a target
environment successfully and on schedule
• Clear and comprehensive release and deployment plans
• Controlled deployment of a new or changed service into
production
• Minimal unpredicted impact on the production services,
operations and support organization
Dr. Lilia SFAXI
Slide 4
Deployment

MedTech
Workflow
• Deployments should be treated as part of a development workflow, not
as an afterthought
• The workflow will usually include at least three environments:
• Development
• Staging
• Production
• Proposed Workflow:
• Developers work on bugs and features in separate branches
• Once features are implemented, they are merged into the staging branch
and deployed to the Staging environment for quality assurance and testing
• After testing is complete, feature branches are merged into the
development branch
• On the release date, the development branch is merged into production and
deployed to the Production environment
Dr. Lilia SFAXI
Slide 5
Deployment

MedTech
Version Control: Branching Workflow by Git
Dr. Lilia SFAXI
Slide 6
Deployment
See a detailed example in:
http://nvie.com/posts/a-successful-git-branching-model/

MedTech
Development Environment
• Environment in which changes to software are developed
• Differs from the ultimate target environment:
• The target may not be a desktop computer (smartphone, embedded
system,…)
• The developer’s environment will include development tools (compiler, IDE,
libraries…) which are not necessarely present in the user’s environment
• Every developer should have his local setup
• Automatic deployment on every commit wastes a lot of time, and correcting
mistakes is tedious
• Testing on a local computer before deployment removes this difficulty
• Only stable versions are pushed to a Staging environment
Dr. Lilia SFAXI
Slide 7
Deployment

MedTech
Staging Environment
• Mirror copy of the production server
• Purpose: test the completed application on the copy of production to ensure
that it won’t break the existant production applications
• No actual code development should take place on a staging server
• Once the features are implemented and considered fairly stable, they get
merged into the staging branch
• It is recommanded to have a branch called staging to represent the staging
environment
• It allows developers to deploy multiple branches to the same server
simultaneously, simply by merging everything that needs to be deployed to the
staging branch.
• At every commit or push in the staging branch, it is recommanded that the
code is deployed to the Staging environment
• Testers go to staging servers and verify that the code works as intended
Dr. Lilia SFAXI
Slide 8
Deployment

MedTech
Production Environment
• Once the feature is implemented and tested, it can be deployed to
production
• If the feature was implemented in a separate branch, it should be
merged into a stable development branch first
• Merge the development branch into production
• Deploy the production branch to your Production environment by hand
or automatically
• Always deploy major releases to production at a scheduled time, of
which the whole team is aware
Dr. Lilia SFAXI
Slide 9
Deployment

MedTech
DEVOPS
Deployment
Dr. Lilia SFAXI
Slide 10

MedTech
DevOps: Definition
• Software for large-scale web sites has been traditionally written by
one group of people (Devs), then released and operated by a different
group (Ops)
• These two groups have very different levels of visibility on how the
software works
Dr. Lilia SFAXI
Slide 11
DevOps

MedTech
DevOps: Definition
• It leads to every role blaming the other when a problem occurs
Dr. Lilia SFAXI
Slide 12
DevOps

MedTech
DevOps: Definition
• A cultural and professional movement, focused on how we build and
operate high velocity organizations, born from the experiences of its
practitioners
• Practice of operations and development engineers participating
together in the entire service lifecycle, from design through the
development process to production support
• Based on 5 principles: CALMS
• Culture: Own the change to drive collaboration and communication
• Automation: Take manual steps out of your value chain
• Lean: Use lean principles to enable higher cycle frequency
• Measurement: Measure everything and use data to refine cycles
• Sharing: Share experiences, successful or not, to enable others to learn
Dr. Lilia SFAXI
Slide 13
DevOps

MedTech
Lean?
• Systematic method for the elimination of waste ("Muda") within a
manufacturing system
• 7 wastes: transportation, inventory, motion, waiting, over-processing, over-
production, defects
• Centered on making obvious what adds value by reducing everything
else.
Dr. Lilia SFAXI
Slide 14
DevOps

MedTech
DevOps vs. Agile
Dr. Lilia SFAXI
Slide 15
DevOps

MedTech
DevOps vs. Agile
Dr. Lilia SFAXI
Slide 16
DevOps

MedTech
Why to Continuous …
• Continuous is one of the most popular words in the DevOps
lexicon
• Almost everything in DevOps is continuous: be it continuous
integration, continuous deployment, continuous delivery,
continuous testing and so on.
• Like many technological concepts, continuous something is
not clearly defined by the DevOps teams
• Most of the times, « continuous » is something of an
exaggeration
• Implies that software changes roll down the pipeline in a totally constant,
never-stopping fashion, which is wrong
Dr. Lilia SFAXI
Slide 17
Continuous something..

MedTech
Continuous Integration
• Changes to code automatically deployed to mainline branch
• After passing unit tests
• Bugs are detected quickly
• « if you have to fail, fail quickly »
• Helps automate deployments
• Use of a continuous integration server (Jenkins, Bamboo..)
• Automatically tests code written by individual developers to make sure it
can be merged into the main code base
• Helps developers to write and test small chunks of code on an ongoing
basis, which minimizes the risk that a code change could cause serious
problems and force developers to revert their application to an earlier
state.
Dr. Lilia SFAXI
Slide 18

MedTech
Continuous Delivery
• The process of delivering software updates to users on a nearly
constant basis
• Made possible by continuous integration and other optimizations at
earlier stages of the development process
• In Continuous Delivery, you aim to have the full software delivery life
cycle automated up until the last environment before production, so
that you are ready at any time to deploy automatically to production.
Dr. Lilia SFAXI
Slide 19

MedTech
Continuous Deployment
• « Process by which our team deploys software changes to
production services over 30 times per day »
• (only theoretically)
• Deployment or release of code to Production as soon as it is
ready.
• Mainly the same as Continuous Delivery, but adding an
automatic trigger to deploy to production.
Dr. Lilia SFAXI
Slide 20

MedTech
Continuous Something in DevOps
Dr. Lilia SFAXI
Slide 21
DevOps

MedTech
DevOps Best Practices
• Automate everything you can
• The more you automate, the more you avoid mistakes that can be done at
deployment
• If you have difficulty automating all the process, automate what you can, and
leave the hard steps to be done manually ( just start!)
• Production should not be such a big deal!
• Keep your staging and production environments consistant
• Staging and Production should be mirror copies, but it is not enough: the
deployment mechanism should be the same too!
• DevOps doesn’t mean « deploying your application to production 30 times a
day »
• It’s not about the number of deployments a day, it’s about being able to deploy
really quickly and easily when the business requires you to
• The faster you get the feedback from production, the quicker developers can
fix it
Dr. Lilia SFAXI
Slide 22
DevOps

MedTech
DevOps Best Practices
• Any change that was not put into production, as far as the final user
is concerned, doesn’t exist
• If a member of the team is hit by a bus…
• Always think of a rollback strategy
• Even for your database, think of a way to maintain old versions for some
time, in case of a mistake
• Even though you have a very strict governance policy (25 people need
to sign in order for deployment to production to take place), you can
still automate the process
• Focus on automated testing, even in production!
Dr. Lilia SFAXI
Slide 23
DevOps

MedTech
References
Dr. Lilia SFAXI
Slide 24
• Intro to DevOps, Udacity,
https://classroom.udacity.com/courses/ud611
• Damian Brady (Solution Architect at Octopus Deploy), DevOps Best
Practices, https://channel9.msdn.com/Shows/DevOps-Dimension/9--
DevOps--Deployment-Automation-Best-Practices
• Deployments Best Practices, Beanstalk Guides,
http://guides.beanstalkapp.com/deployments/best-practices.html

Software Engineering - chp8- deployment

More Related Content

What's hot

Viewers also liked

Similar to Software Engineering - chp8- deployment

More from Lilia Sfaxi

Recently uploaded

In this document

Software Engineering - chp8- deployment