CS427: Software Engineering I Grigore Rosu

Today’s goals Quick Logistics Software Configuration Management Version control: git Build: maven

Course Logistics Wiki: http://wiki.cites.illinois.edu/wiki/display/cs427fa17 (videos!) Piazza: https://piazza.com/class#fall2017/cs427 Compass: https://compass2g.illinois.edu All class-wide announcements through compass or my.cs MP0 due today, 23:59; MP1 out today, 23:59 Follow the rules and the format specified on Wiki! MP1 due Wednesday, but recommended Monday (easy MP!) MP2 will be released on Monday and due in one week Reminder MPs (30%), final exam (25%), project (40%), quizzes (5%) Bonus up to 3% for active participation (lectures, Piazza, …) Lots of “broad but shallow” reading Read, read, read everything we list on the wiki Book chapters and papers will be on EXAM

Software Configuration Management (SCM)

SCM SCM Definition, by the Software Engineering Institute (SEI) Discipline for controlling the evolution of software systems Four major aspects, among many other: Change control Version control Building Releasing Supported by tools Requires expertise and oversight More important on large projects

Software product Product = set of components/documents Code Test suites Operation manuals (admins, end-users) Requirements Specifications Design documentation Plans/schedules

Software products Need to keep track of how they were created Rules for building the executable Version of code Version of libraries The compiler The operating system SCM tool should be able to keep track of all of these And more

SCM Keep track of how product changes over time and be able to reproduce any version of it Control how product changes; make sure needed changes have been made and no improper changes have been made

SCM SCM Definition, by the Software Engineering Institute (SEI) Discipline for controlling the evolution of software systems Four major aspects, among many other: Change control Version control Building Releasing Supported by tools Requires expertise and oversight More important on large projects

Version Control Simple Example Continuously editing a file … How to keep track of changes?

The Good Old Way The good old way: myFile-1.txt myFile-2.txt What did I change? When did that happen??

The Good Old Way The good old way: myFile-1.txt myFile-2.txt myFile-aug4morning.txt myFile-aug4-later-in-the-morning.txt myFile-aug4-evening.txt myFile-aug9.txt myFile-final.txt myFile-latest.txt myFile-last.txt myFile-final-final.txt

Version Control System (VCS) To The Rescue!

VCS: What and Why? A Version Control System (VCS) is a software system that keeps track of the changes made to a set of files so that you can recall a specific version. It gives you the power to: Collaborate on a project with multiple other developers, merging changes and resolving conflicts Revert changes Go back in time to a specific version (tags can be your friend) Some of most popular (open source): GIT, SVN, CVS We will use GIT in CS427

VCS: Creating/Cloning a Local Copy of Remote Repository Server Side (remote) e.g., github, gitlab Create/Clone a local copy Client 2 Client n Client 1

GIT: Creating/Cloning a Local Copy of Remote Repository To create/clone local copy of the remote repository: git clone https://gitlab.engr.illinois.edu/<netID>/cs427fa17.git A local copy named cs427fa17 is created that replicates your remote repository on gitlab, and puts it in a directory named cs427fa17 git is now setup to track any changes to your local copy that you want to keep track of (see next slide) You should do the above on all the machines on which you want to have a local copy of the remote repository

VCS: Commit/Push Local Changes Server Side (remote) e.g., github, gitlab Commit then push local changes to the server VM Desktop Laptop Local changes (to existing files, for now) – say updating your MP

git: Commit/Push Local Changes Change files as desired (for now only ones that already exist in the repository; we’ll add new ones shortly). To see what tracked files were changed: git status To commit your changes to tracked files onto your local repository: git commit -m “A meaningful commit message” To push your commit(s) to your remote repository: git push origin master

VCS: Updating Other Local Copies Server Side (remote) e.g., github, gitlab Update your other local copies to be in sync with the server VM Desktop Laptop

git: Updating Other Local Copies To update your other local copies with the changes on the server, for example your local copy on the VM in order to test your MP before deadline, go to the local copy you want to update and type: git pull All the git commands shown above take lots of options. If you need to do/learn more, start with: git help

VCS: Adding New File to Track Server Side (remote) e.g., github, gitlab Tell VCS about the new file to track Commit and push the change to the server VM Desktop Laptop Locally added new file

git: Adding New File to Track To track a new file: git add mp0/test.txt Then the added file becomes like any other tracked file that has changed, so you can use the commands you already know to check the status of, to commit, or to push your changes

(A Lot!) More Commands git help Pro GIT: https://git-scm.com/book/en/v2

Version control workflow Repository - contains complete history pull (or “checkout”, in SVN terminology) latest version Hack, hack, hack, … commit and then push (or “checkin”, in SVN), making a new version of the software

Version control parallel work What happens if Two people are changing same code at the same time? Jack pulls V23, changes it, and pushes V24 Jill also pulls V23, changes it, and pushes ???

Version control parallel work So what happens if two people are changing same software at same time? One solution (locking): Infeasible, does not scale! First person must lock software before making changes. Second person must wait until lock is released. Another solution (merging): The second person to check in the software must merge the changes. Automatic merging works most of the time (but can silently introduce bugs).

Version control: no locking (!) Locking is bad because it forces you to wait when you want to get work done “John has locked ELFReader.java, but he is on vacation. Can you break the lock?”

Version control: merging risk Merging can sometimes produce errors: Two people change the same line. System will force the one merging the changes to perform the merge manually. Changes don’t seem to conflict, but merging may still cause a bug, which may or may not be easy to catch.

Golden rule of VCS Commit and push frequently! The longer you have code uncommitted/unpushed The more you interfere with others The harder it is to merge later Break work into small steps. Finish each step the same day you start it, commit, push. Try to avoid long lasting branches

SCM SCM Definition, by the Software Engineering Institute (SEI) Discipline for controlling the evolution of software systems Four major aspects, among many other: Change control Version control Building Releasing Supported by tools Requires expertise and oversight More important on large projects

Build management How do you build the product? Which compiler? Which flags? Which source files? Which libraries should be linked? “Which” also means “which version”

Building Building should be automatic Test build procedure - build regularly Need a tool make – Original Unix tool, 30 years old ant – Java based, uses XML mvn – used in CS427 Dozens more …

Build tool Knows components of system How to compile How to make final executable How to make debugging version How to delete temporary files How to test How to make documentation …

Maven (mvn) DEMO (Daejun Park) Let’s try to build manually and then automate it

Class Exercise (while Daejun sets up) How do you build your software? What is the most annoying issue of your build system? What missing feature would you like it to have? Groups of 3 students 5 Minutes

<project xmlns="http://maven. apache. org/POM/4 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>cs427</groupId> <artifactId>myClass</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> </plugin> </plugins> </build> </project> Maven snippet

Daily build smoke tests Many ways to break the build process: Check in bad code Forget to include/add file Move a library Every day (night) build the latest version of product and run simple test suite (smoke tests)

Developer issues Good Practice Private Workspace Prevent integration issues from distracting you, and from your changes causing others problems, by developing in a Private Workspace. Private System Build Avoid breaking the build by doing a Private System Build before committing changes to the Repository These and many other “development rules” are typically enforced by companies