1. CS427: Software Engineering I
Grigore Rosu

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

3. Course Logistics
Wiki: (videos!)
Piazza:
Compass:
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

4. Software Configuration Management (SCM)

5. 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

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

7. 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

8. 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

9. 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

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

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

12. 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

13. Version Control System (VCS) To The Rescue!

14. 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

15. 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

16. GIT: Creating/Cloning a Local Copy of Remote Repository
To create/clone local copy of the remote repository:
git clone
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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. (A Lot!) More Commands git help
Pro GIT:

24. 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

25. 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 ???

26. 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).

27. 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?”

28. 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.

29. 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

30. 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

31. 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”

32. 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 …

33. 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 …

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

35. 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

36. <project xmlns="http://maven. apache. org/POM/4
<project xmlns=" xmlns:xsi="
xsi:schemaLocation="
<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

37. 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)

38. 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