Continuous Integration / Continuous Testing

Size: px

Start display at page:

Download "Continuous Integration / Continuous Testing"

Lenard Whitehead
5 years ago
Views:

1 Bitte decken Sie die schraffierte Fläche mit einem Bild ab. Please cover the shaded area with a picture. (24,4 x 7,6 cm) Continuous Integration / Continuous Testing IIC

2 What s SW Integration? Integration approaches What s SW Integration? Integration strategy? 2

3 Integration strategy Bottom Up integration approach Top down integration approach Big bang integration approach Stubs (top-down) and drivers (bottom-up) are used to replace the missing software and simulate the interface between the software components in a simple manner. 3

Bottom Up integration approach Components or systems are substituted by drivers. To understand what a driver is, suppose you have finished Function B and is waiting for Function A to be developed.

4 Bottom Up integration approach Components or systems are substituted by drivers. To understand what a driver is, suppose you have finished Function B and is waiting for Function A to be developed. In this case you create a dummy to call the Function B. This dummy is called the driver. Dummy codes are basically fake codes that help in simulating the behavior of existing codes. That means developer can use dummy codes in place of that code which is not written yet in order to replicate the outputs of the original code. 4

5 Top Down integration approach Components or systems are substituted by stubs Suppose you have a function (Function A) that calculates the total marks obtained by a student in a particular academic year. Suppose this function derives its values from another function (Function B) which calculates the marks obtained in a particular subject. You have finished working on Function A and wants to test it. But the problem you face here is that you can't seem to run the Function A without input from Function B; Function B is still under development. In this case, you create a dummy function to act in place of Function B to test your function. This dummy function gets called by another function. Such a dummy is called a Stub. 5

6 Big Bang integration approach 6

7 What s Continuous Integration, CI? Continuous integration is simply a practice that requires developers to integrate code into a shared repository several times a day. Commit Build Report Test Continuous Integration doesn t get rid of bugs, but it does make them dramatically easier to find and remove. Martin Fowler, Chief Scientist, ThoughtWorks Monitor 7

8 What s Continuous Integration, CI? Each check-in is verified by an automated build, allowing teams to detect problems early. By integrating regularly, you can detect errors quickly, and locate them more easily. Development Branches Mainline Classic Integration Mainline Continuous Integration 8

9 Continuous Integration Principles Maintain a single source repository Automate the build Make your build self-testing Every commit should build on an integration machine Keep the build fast Test in a clone of the production environment (staging) Make it easy for anyone to get the latest executable version Everyone can see what s happening Automate deployment 9

10 Different tools contributing to CI 10

11 Source Code Management (SCM) SCM, also known as revision control or the management of source code. version control, is 11

12 SCM - Terminology repository: the repository is where files' current and historical data are stored, often on a server baseline: an approved revision of a document or source file from which subsequent changes can be made branch / fork: a set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other checkout: to check out is to create a local working copy from the repository, a user may specify a specific revision or obtain the latest commit: to commit (check in) is to write or merge the changes made in the working copy back to the repository, the term can also be used as noun to describe the new revision that is created as a result of committing merge: a merge or integration is an operation in which two sets of changes are applied to a file or set of files 12

13 SCM Workflow example 13

Code Collaboration Code collaboration / Code review is

development, improving the overall quality of software.

14 Code Collaboration Code collaboration / Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in software development, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections. 14

15 Continuous Integration Services 15

16 JENKINS Jenkins is an open-source continuous integration software tool written in the Java programming language for testing and reporting on isolated changes in a larger code base in real time. Jenkins offers the following major features out of the box, and many more can be added through plugins: 1. Easy installation: Jenkins is a self-contained Java-based program, ready to run out-ofthe-box, with packages for Windows, Mac OS X and other Unix-like operating systems. 2. Easy configuration: Jenkins can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. 3. Rich plugin ecosystem: Jenkins integrates with virtually every SCM or build tool that exists. View plugins. 4. Extensibility: Most parts of Jenkins can be extended and modified, and it's easy to create new Jenkins plugins. This allows you to customize Jenkins to your needs. 5. Distributed builds: Jenkins can distribute build/test loads to multiple computers with different operating systems. Building software for OS X, Linux, and Windows? No problem. 16

17 17

18 18

19 19

20 TeamCity TeamCity is a user-friendly continuous integration (CI) server for developers and build engineers free of charge with the Professional Server License and easy to set up. 1. Continuous Integration & Testing - The delayed commit feature allows you to always keep builds working and the project code base clean. Developers' code modifications are submitted into version control only if all the tests pass. Failures are immediately reported and are visible online for the entire team 2. Efficient, Effective Build Management - Define and run different build types with different build configurations for any project, customize build triggers, for flexible management of the build process. 3. Code Quality Maintenance - Highest code quality is maintained with server-side code analysis features (600+ Java code inspections, inherited from IntelliJ IDEA) and by searching for code duplicates and performing code coverage analysis. This also frees up developers' local computing resources 4. IDE-friendly Solution - Eclipse, IntelliJ IDEA, and MS Visual Studio Integration. TeamCity comes with many plugins for Eclipse, Microsoft Visual Studio, and IntelliJ IDEA, which provide all the productivity features right in the IDE 5. Web-based Interface & Project Dashboard - A late-model web browser is also enough to work with TeamCity, making you independent of IDEs or programming languages. The project dashboard helps all team members stay up-to-date on the status of current builds and provides effective and painless navigation through large amounts of test/build-related information 20

21 21

22 22

23 23

24 Continuous Integration with Jenkins CM Database Developer 1. Check-in task (commit) 2. Trigger 3. Starts testing 4. Collects results 24

25 Continuous Integration, Delivery and Deployment Continuous Integration: Highly automated process from development to integration and redistribution of good tasks (commits) to the development team. Continuous Delivery: Highly automated process through all stages from development to Ready to deliver to production or customer, but a manual decision is taken before final delivery. Continuous Deployment: One step more: Deploy to production / customer without manual decision, if every test was passed. 25

26 What is the difference between Continuous Integration, Continuous Deployment & Continuous Delivery? 26

27 CI Levels CI Level 0 (Central repository): Central repository is maintained, but no automation is used. CI Level 1 (Daily, nightly, weekly build): Automated build started manually or time based. CI Level 2 (Triggered builds): Triggered by commit independent of success. CI Level 3 (Continuous builds): Always based on the latest successfully integrated branch. CI Level 4 (Gated commits): Quality measures taken by the submitter. Only if these quality tests are passed the commit is really applied to the central repository. CI Level 5 6 As for CI Level 4 the levels 5 and 6 introduce quality gates but on higher level e.g. on component level for level 5 and on release level for level 6. 27

28 No Continuous Integration at all + Developers work in stable, isolated environment and are not disturbed by other s work - Branches diverge - Refactoring very difficult - Challenging and risky integration Development Branches Mainline 28

29 L-0: Common mainline (local checks by developer) + Developers are aware of each other s changes + Merge conflicts are detected and resolved early, before they grow bigger and bigger - There is no quick feedback if the mainline is in working order after the commit But it works on my machine Mainline 29

30 L-1: Nightly builds (time triggered checks) + There is a clear indication if the mainline degrades and doesn t work any more - It is not possible to attribute build failures to individual commits Mainline 30

31 L-2: Change Management triggered checks + Very quick feedback when a commit breaks the build + Status of mainline visible at any time - Requires some discipline on developers - Modifications in a Change Package potentially very big Mainline 31

32 L-3: Continuous Integration + Very quick feedback when a commit breaks the build + Status of mainline visible at any time - Requires some discipline on developers Application of delta (integration) Build and test Discard change Application of fix delta (integration) Build and test Mainline Local Change User branch 32

33 L-4: Gated commits also known as pre-tested commits + Mainline is always in working order + Checks can be more thorough, as they are not that time critical + Can involve manual reviews as well - Requires robust change propagation in Configuration Management system - Requires review infrastructure (optional and recommended) Application of delta (integration) Build and test Build and test Mainline Stash Local Change Discard change Application of fix delta (integration) User branch 33

34 L-5: Continuous Delivery into Test + Features are quickly provided to customer - Requires high degree of test automation to keep effort reasonable Staging Mainline 34

35 L-6: Continuous Delivery into Production + Features are quickly provided to customer, not waiting for scheduled releases - Requires high degree of test and deployment automation to keep effort reasonable Staging Mainline 35

36 Integration evolution to Continuous Delivery Manual Big Bang Integration Manual Continuous Integration Automated CI via Jenkins Continuous Delivery Continuous Delivery: After each successful integration a delivery towards the next Integration site is made Currently four customer projects gets something like Continuous Delivery : For two packages in case code has changed a delivery is done 1 4 times a day (This is enough since currently the customer projects can t take it more often). For two packages a delivery after each change/release is done. 36

37 Continuous Testing Advantages of Continuous Integration Testing Continuous integration has many advantages. When tests fail or bugs emerge, developers can revert the codebase to a bug-free state without wasting time debugging. Developers can detect and fix integration problems continuously and thus avoid last-minute chaos at release dates. In addition, CI testing provides: Early warning of broken/incompatible code Early warning of conflicting changes Immediate testing of all changes Constant availability of a current build for testing, demo, or release purposes Immediate feedback to developers on the quality, functionality, or system-wide impact of their written code Frequent code check-ins push developers to create modular, less complex code 37

DevOps DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops).

38 DevOps DevOps (a clipped compound of "development" and "operations") is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives. 38

Traceability An important principle of change

between issue management (i.e. JIRA) and the code repository (via Gerrit).

JIRA issues and we also know which commits were

39 Traceability An important principle of change management is to have two-way traceability between issue management (i.e. JIRA) and the code repository (via Gerrit). In this way, individual commits can be traced to JIRA issues and we also know which commits were used to resolve a JIRA issue. 39

40 Bibliography Advantages of Continuous Integration Testing

41 41

Bitte decken Sie die schraffierte Fläche mit einem Bild ab. Please cover the shaded area with a picture. (24,4 x 7,6 cm)

Bitte decken Sie die schraffierte Fläche mit einem Bild ab. Please cover the shaded area with a picture. (24,4 x 7,6 cm) Continuous Integration / Continuous Testing Seminary IIC Requirements Java SE Runtime