software engineering - chp8- deployment

MedTech

Chapter 8 – Deployment

Deployment Process, Best Pratices, DevOps

Dr. L i l ia SFAXIwww. l i l iasfax i .wix .com /l i l iasfax i

S l id e 1

MedTech – Mediterranean Institute of TechnologyCS321-Software Engineering

MedTech

MedTech

INTRODUCTION TO DEPLOYMENTDeployment


S l id e 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. L i l ia SFAXI www. l i l iasfax i .wix .com /l i l iasfax i

S l id e 3

Deployment

MedTech

Objectives

• Efficiently build, install, test and deploy releases to a targetenvironment successfully and on schedule

• Clear and comprehensive release and deployment plans

• Controlled deployment of a new or changed service intoproduction

• Minimal unpredicted impact on the production services, operations and support organization


S l id e 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


S l id e 5

Deployment

MedTech

Version Control: Branching Workflow by Git


S l id e 6

Deployment

See adetailed 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


S l id e 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


S l id e 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 bemerged 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


S l id e 9

Deployment

MedTech

DEVOPSDeployment


S l id e 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 differentgroup (Ops)• These two groups have very different levels of visibility on how the

software works


S l id e 11

DevOps

MedTech

DevOps: Definition

• It leads to every role blaming the other when a problem occurs


S l id e 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 itspractitioners

• Practice of operations and development engineers participatingtogether 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


S l id e 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 everythingelse.


S l id e 14

DevOps

MedTech

DevOps vs. Agile


S l id e 15

DevOps

MedTech

DevOps vs. Agile


S l id e 16

DevOps

MedTech

Why to Continuous …

• Continuous is one of the most popular words in the DevOpslexicon

• Almost everything in DevOps is continuous: be it continuousintegration, continuous deployment, continuous delivery, continuous testing and so on.

• Like many technological concepts, continuous something isnot 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


S l id e 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 itcan be merged into the main code base

• Helps developers to write and test small chunks of code on an ongoingbasis, which minimizes the risk that a code change could cause seriousproblems and force developers to revert their application to an earlierstate.


S l id e 18


MedTech

Continuous Delivery

• The process of delivering software updates to users on a nearlyconstant 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, sothat you are ready at any time to deploy automatically to production.


S l id e 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 isready.

• Mainly the same as Continuous Delivery, but adding an automatic trigger to deploy to production.


S l id e 20


MedTech

Continuous Something in DevOps


S l id e 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 canfix it


S l id e 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!


S l id e 23

DevOps

MedTech

References


S l id e 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