Charlie Garrod Bogdan Vasilescu School of Computer Science 17-214 - - PowerPoint PPT Presentation

▶
charlie garrod bogdan vasilescu
SMART_READER_LITE
LIVE PREVIEW

Charlie Garrod Bogdan Vasilescu School of Computer Science 17-214 - - PowerPoint PPT Presentation

Nov 16, 2023 447 likes •991 views

Principles of Software Construction: Objects, Design, and Concurrency Managing change Charlie Garrod Bogdan Vasilescu School of Computer Science 17-214 1 Lambdas and streams GUIs UML More Git Intro to Java Static Analysis DevOps Git,

slide-1
SLIDE 1

1

17-214

School of Computer Science

Principles of Software Construction: Objects, Design, and Concurrency Managing change

Charlie Garrod Bogdan Vasilescu

slide-2
SLIDE 2

2

17-214

Part 1: Design at a Class Level Design for Change: Information Hiding, Contracts, Unit Testing, Design Patterns Design for Reuse: Inheritance, Delegation, Immutability, LSP, Design Patterns Part 2: Designing (Sub)systems Understanding the Problem Responsibility Assignment, Design Patterns, GUI vs Core, Design Case Studies Testing Subsystems Design for Reuse at Scale: Frameworks and APIs Part 3: Designing Concurrent Systems Concurrency Primitives, Synchronization Designing Abstractions for Concurrency

Intro to Java Git, CI Static Analysis GUIs UML Lambdas and streams More Git DevOps More design patterns Performance Design

slide-3
SLIDE 3

3

17-214

Administrivia

  • Homework 6 checkpoint deadline (Monday, April 30th)
  • Homework 6 due Wednesday, May 2nd
  • Final exam Monday May 7th 5:30-8:30 PH 100
  • Review session Saturday May 5th
slide-4
SLIDE 4

4

17-214

Key concepts from Carnival

slide-5
SLIDE 5

5

17-214

Scenario

A customer wants a bug fix to software version 8.2.1, which was released 2 years ago. How to make sure we can fix, build, and release?

slide-6
SLIDE 6

6

17-214

Configuration Management (CM)

Pressman: “is a set of tracking and control activities that are initiated when a software engineering projects begins and terminates when software is taken out of operation”

Configuration management originates from the 50s, when spacecraft failures resulted from undocumented changes.

slide-7
SLIDE 7

7

17-214

The Modern World

Complex Source Languages, Directories, Dependencies Source Files Data Versioning Branching Many Tools Compilers, Linkers, Code gens, Translators Traceability Scalability Configuring Complex Systems Executables Libraries Dependencies Config Files Data Consistency Flexibility

Cloud Deployment Distributed Data Virtualization Load Balancing Security

Diverse User Base

Many Platforms Product Lines Shared Libraries Security Localization

slide-8
SLIDE 8

8

17-214

The Modern World

  • Which Version?
  • How to recreate?
  • How to fix?
  • Where to apply the fix?
  • How/when to

Redistribute?

slide-9
SLIDE 9

9

17-214

Components of Modern CM

Version Control + Workflows Build Managers Package Managers Deployment Managers + VMs/ Containers App Markets + Update Managers

slide-10
SLIDE 10

10

17-214

Configuration management as safety net

  • Doing software development without CM is “working without

a safety net”

  • Configuration management refers to both a process and a

technology

– The process encourages developers to work in such a way that changes to code are tracked

  • changes become “first class objects” that can be named, tracked,

discussed and manipulated – The technology is any system that provides features to enable this process

slide-11
SLIDE 11

11

17-214

Activity

In pairs, discuss other reasons why we may want configuration management Some reasons

  • “Works for me”; difficulty onboarding new devs, installing

dependencies

  • Audits: Discovery request on changes made to system (e.g. no

tracking in breathalyzer lawsuit)

  • Product lines (Home, Business, Professional); different

customer types.

  • Markets: Asia, Europe, America (Language + feature variance)
  • Platforms: Windows, Mac OS, Android, iOS
slide-12
SLIDE 12

12

17-214

CM is a key part of DevOps (more later)

slide-13
SLIDE 13

13

17-214

Components of Modern CM Version Control: Branches/Forks/Workflows Task and Build managers Build machines, virtual environments (dev stacks) Package managers Containers, VMs, in the Cloud Deployment – Infrastructure as Code. Data migration Other issues: orchestration, inventory, compliance

slide-14
SLIDE 14

14

17-214

  • Config. management vs version control
  • “version control” is “versioning” applied to a single file

while “configuration management” is “versioning” applied to collections of files

slide-15
SLIDE 15

15

17-214

VERSION CONTROL WITH GIT

slide-16
SLIDE 16

16

17-214

  • A. GOAL: COLLABORATION ON FILES
slide-17
SLIDE 17

17

17-214

Collaborating on Files

  • How to exchange files

– Send changes by email – Manual synchronization at project meeting – All files on shared network directory

  • Permission models

– Each file has an owner; only person allowed to change it – Everybody may change all files (collective ownership)

slide-18
SLIDE 18

18

17-214

Concurrent Modifications

  • Allowing concurrent modifications is challenging
  • Conflicts (accidental overwriting) may occur
  • Common strategies

– Locking to change – Detecting conflicts (optimistic model)

slide-19
SLIDE 19

19

17-214

Change Conflicts

source „Version Control with Subversion“

slide-20
SLIDE 20

20

17-214

Locking Files

Practical problems of locking model?

slide-21
SLIDE 21

22

17-214

Merging (1/2)

slide-22
SLIDE 22

23

17-214

Merging (2/2)

slide-23
SLIDE 23

24

17-214

Example

slide-24
SLIDE 24

25

17-214

Example

E d i t 2 Edit 1

slide-25
SLIDE 25

26

17-214

Example

Einführung in die Softwaretechnik 26

Merge M e r g e

System cannot decide order

slide-26
SLIDE 26

27

17-214

3-way merge

  • File changed in two ways

– Overlapping changes -> conflicts – Merge combines non-conflicting changes from both

  • Merging not always automatic

– diff tool to show changes – Manual resolution of conflicts during merge (potentially requires additional communication)

  • Automatic merge potentially dangerous
  • > syntactic notion of conflicts
  • Merging of binary files difficult
  • In practice: most merges are conflict free
slide-27
SLIDE 27

28

17-214

  • B. GOAL: RELEASE MANAGEMENT
slide-28
SLIDE 28

29

17-214

Challenge:

  • Refer to concrete consistent versions of the project (code and all

dependencies and infrastructure)

  • Why?

– Parallel development of independent features – Bug fixes for old releases; patches – Variants for different customers – Traceability and accountability of changes (provenance)

slide-29
SLIDE 29

30

17-214

Branching

  • Parallel copies of the source tree
  • Can be changed independently, versioned separately, and

merged later (or left separate)

  • Often used for exploratory changes or to isolate development

activities

  • Many usage patterns, common:

– Main branch for maintenance OR main development – New branches for experimental features; merge when successful – New branches for nontrivial maintenance work – Branches for maintenance of old versions

slide-30
SLIDE 30

31

17-214

Release management with branches

slide-31
SLIDE 31

32

17-214

Release cycle of Facebook’s apps

slide-32
SLIDE 32

33

17-214

Variants and Revisions

  • Revision replaces prior revision (temporal)
  • Variant coexists with other variants
  • Version describes both
  • Release: Published and named version

V1.0 V2.0 V3.0 V1.1 Base system (Windows) Extension for customer A Extension for customer B Linux variant Server variant

X X X X X X X X X X X X

slide-33
SLIDE 33

34

17-214

Semantic Versioning for Releases

  • Given a version number MAJOR.MINOR.PATCH, increment the:

– MAJOR version when you make incompatible API changes, – MINOR version when you add functionality in a backwards-compatible manner, and – PATCH version when you make backwards-compatible bug fixes.

  • Additional labels for pre-release and build metadata are

available as extensions to the MAJOR.MINOR.PATCH format. http://semver.org/

slide-34
SLIDE 34

36

17-214

Managing variants

  • Branching for variants does not scale well
  • Requires special planning or tooling
  • Many solutions

– Configuration files – OO polymorphism – Preprocessors – Build systems – DSLs – Software product lines – …

slide-35
SLIDE 35

37

17-214

  • C. TYPES OF VERSION CONTROL
slide-36
SLIDE 36

39

17-214

Centralized version control

  • Single server that

contains all the versioned files

  • Clients check out/in

files from that central place

  • E.g., CVS, SVN

(Subversion), and Perforce

https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

slide-37
SLIDE 37

40

17-214

Distributed version control

  • Clients fully mirror the

repository

– Every clone is a full backup of all the data

  • E.g., Git, Mercurial,

Bazaar

https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

slide-38
SLIDE 38

42

17-214

SVN (left) vs. Git (right)

  • SVN stores changes to a base

version of each file

  • Version numbers (1, 2, 3, …)

are increased by one after each commit

  • Git stores each version as a

snapshot

  • If files have not changed, only a

link to the previous file is stored

  • Each version is referred by the

SHA-1 hash of the contents

https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control

slide-39
SLIDE 39

43

17-214

Which files to manage (both types)

  • All code and noncode files

– Java code – Build scripts – Documentation

  • Exclude generated files (.class, …)
  • Most version control systems have a mechanism to exclude files

(e.g., .gitignore)

slide-40
SLIDE 40

44

17-214

Activity

  • In pairs, discuss advantages and disadvantages of centralized

(e.g., SVN) vs decentralized (e.g., git) version control

slide-41
SLIDE 41

46

17-214

  • D. GIT BASICS

Graphics by https://learngitbranching.js.org

slide-42
SLIDE 42

47

17-214

git commit

slide-43
SLIDE 43

48

17-214

git branch newImage

slide-44
SLIDE 44

49

17-214

git commit

slide-45
SLIDE 45

50

17-214

git checkout newImage; git commit

slide-46
SLIDE 46

51

17-214

Activity: Make a new branch named bugFix and switch to that branch

slide-47
SLIDE 47

52

17-214

1) git merge bugFix

slide-48
SLIDE 48

53

17-214

git checkout bugfix; git merge master

slide-49
SLIDE 49

54

17-214

Activity:

slide-50
SLIDE 50

55

17-214

2) git rebase master

Move work from bugFix directly onto master

slide-51
SLIDE 51

56

17-214

git rebase bugFix

slide-52
SLIDE 52

57

17-214

To be continued …

slide-53
SLIDE 53

70

17-214

Summary

  • Version control has many advantages

– History, traceability, versioning – Collaborative and parallel development

  • Locking vs. merging and merge conflicts
  • Collaboration with branches
  • From local to central to distributed version control