tmf2014 ci-cd workshop michael palotas

Post on 13-May-2015

205 Views

Category:

Technology

4 Downloads

Preview:

Click to see full reader

DESCRIPTION

A very big thank you to Michael Palotas from Grid Fusion & eBay International for taking the time and effort to travel across the globe to present at the Australian Test Managers Forum 2014. If you would like any information on TMF please email tmf@kjross.com.au

TRANSCRIPT

TEST MANAGERS FORUM 2014 SYDNEY, AUSTRALIA CONTINUOUS INTEGRATION CONTINUOUS DELIVERY

1

2

WHO AM I? Gridfusion Software Solutions Contact: Michael Palotas Gerbiweg 2 8853 Lachen SWITZERLAND Tel.: +41 79 6690708 Email: michael.palotas@gridfusion.net

Head of Productivity & Test Engineering, eBay

Founder / Principal Consultant Gridfusion Software Solutions

SETTING THE STAGE

Tell me about yourself J

What are your expectations for today?

3

Your setup

How do you build software?

4

WHAT IS SO SPECIAL ABOUT AGILE?

5

WHY CI/CD?

6

WHAT IS IMPORTANT IN AGILE?

7

Agile

=

Release working software anytime

8

Traditional waterfall model / tools do not support “build and deploy anytime”

9

WHAT IS CI / CD?

CI and CD

=

Automated Build?

Automated Tests?

Automated Quality?

Automated Deployment?

Automated Feedback?

10

WHY CI / CD

Deliver value to the business more frequently

Better Quality

Early Bugs

Bug Prevention instead of late detection

Fast & frequent feedback

11

WHY CI / CD

Automated frequent builds

Automated frequent tests

Automated frequent code quality metrics

(Hopefully) Fewer bugs

Fast feedback

12

WITHOUT CI

Slow / long release cycles

Late testing

Waterfall (WaterScrum)

Bugs

Slow feedback

Complex integration

13

CORE PRINCIPLES

Every build could be a release

Everything should be automated

Stable and trustworthy automated tests

Build pipelines

14

RELEASING IN THE OLD WORLD

15

Coding

Deploy to

QA

QA

Deploy to Production

Production Smoke Tests

Bug Bashes

CI / CD - CORE WORKFLOW

16

Compile

Unit Test

Deploy to QA

Acceptance tests

Deploy to Production

Production Smoke Tests

Code Quality

THE MAIN TASKS

Automated build

Automated code quality

Automated testing

Automated deployment

17

18

Wakaleo.com

CAN YOU MEASURE AUTOMATED CODE QUALITY? DOES THAT MAKE SENSE?

19

AUTOMATED CODE QUALITY?

Sonar gives you information on:

-  Lines of code

-  % of comments

-  Duplications

-  Complexity

-  Rules compliance

-  Unit test coverage

-  Unit test success rate

-  Unit test duration

-  Hotspots

20

CAN / SHOULD YOU AUTOMATE EVERYTHING?

21

WHAT SHOULD YOU AUTOMATE?

22

WHAT ARE BARRIERS TO CI / CD?

23

WHAT IS CONTIUOUS INTEGRATION?

24

Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming (XP). Its main aim is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI can be seen as an intensification of practices of periodic integration advocated by earlier published methods of incremental and iterative software development, such as the Booch method. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each.

WHAT IS CONTINUOUS DELIVERY?

25

Continuous Delivery (CD) is a design practice used in software development to automate and improve the process of software delivery. Techniques such as automated testing, continuous integration and continuous deployment allow software to be developed to a high standard and easily packaged and deployed to test environments, resulting in the ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead. The technique was one of the assumptions of extreme programming but at an enterprise level has developed into a discipline of its own, with job descriptions for roles such as "buildmaster" calling for CD skills as mandatory.

THE MANAGEMENT / ORGANIZATIONAL ASPECT

What are the changes for developers and testers?

What needs to be changed in the organization to enable them to implement CI / CD?

What role has management in creating a devops culture?

26

OUR TOOLS

Version Control System GIT Build Tool MAVEN Unit Test Framework JUNIT / TESTNG End To End Test Framework SELENIUM Build Server / Deployment JENKINS

27

Branching & Merging

Small and Fast

Distributed

Data Assurance

Staging Area

Free and Open Source

VERSION CONTROL: GIT

28

http://git-scm.com/about/

GIT: BRANCHING & MERGING

29

Git-scm.com

GIT: SMALL & FAST

30

Git-scm.com

GIT: THE REST

Distributed

Data Assurance

Staging Area

Free & Open Source

31

GIT

Distributed / local

Download: http://git-scm.com/

Initialize directory: git init

Status: git status

Add files and directories to git: git add file1 dir2

Commit: git commit –am “commit message”

32

SHARE YOUR CODE - GITHUB

Create repository on Github: https://github.com

Create remote: git remote add origin https://…

Push code to Github: git push origin master

Tag your code: git tag –a v0.1 –m “initial version”

Push tag to Github: git push origin v0.1

33

GITHUB

34

CONNECT GIT AND GITHUB

35

Silverpeas.org

MAVEN

36

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.

http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html

POM.XML

The pom.xml file is the core of a project's configuration in Maven. It is a single

configuration file that contains the majority of information required to build a project in just

the way you want.

37

POM.XML

38

MAVEN TARGETS

validate: validate the project is correct and all necessary information is available

compile: compile the source code of the project

test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed

package: take the compiled code and package it in its distributable format, such as a JAR.

integration-test: process and deploy the package if necessary into an environment where integration tests can be run

verify: run any checks to verify the package is valid and meets quality criteria

install: install the package into the local repository, for use as a dependency in other projects locally

deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

clean: cleans up artifacts created by prior builds

39

EXAMPLES

mvn clean

mvn compile

mvn test

40

CONTINUOUS INTEGRATION - JENKINS

Download at http://jenkins-ci.org/

41

RECAP

WHAT DO WE EXPECT

THE CI SYSTEM TO DO?

42

43

A JENKINS JOB

44

WHAT JENKINS DOES

Jenkins checks out the workspace from Github

Builds and runs tests locally according to POM

Runs maven targets according to POM description

45

A SIMPLE BUILD JOB

46

A SIMPLE BUILD JOB

1.  Add / change some code

2.  Push to Github repository

3.  Let Jenkins pick up the change

4.  Perform mvn clean compile targets

5.  Perform mvn test target (unit tests only)

47

TEST AUTOMATION

Unit Tests

E2E Tests

Manual Tests

Integration Tests

WHAT IS SELENIUM?

Selenium automates browsers

that’s it

E2E / UAT AUTOMATION WITH SELENIUM

50

CLIENT

SERVER JSON Wire Protocol

BROWSER

SELENIUM

JSON WIRE PROTOCOL

Client

Java

C#

Ruby

Python

Server Driver

Driver

Driver

CLIENT

Is seen as „Selenium“ by the users

Generates HTTP requests which are received by the server

Is called by the test framework or the CI server

Supported languages: Java, C#, Python, Ruby, Perl, PHP,

JS

SERVER

Receives HTTP requests

Start and teardown of browser

Translates requests into browser specific commands

Communicates back to the client

SELENIUM GRID Sequential Execution

Test 1 Test 2 Test …

Test 4500

Execution Time

Test 3

Parallel Execution

Test Test Test

Execution Time

Test

Test Test Test Test

Test Test Test Test

Par

alle

l Exe

cutio

n

Par

alle

l Exe

cutio

n

SELENIUM GRID

TEST INFRASTRUCTURE

AUT

DB

API

Browsers Mobiles

CLIENT

57

A SIMPLE SELENIUM TEST

58

59

LET’S BUILD A BUILD / DEPLOYMENT PIPELINE

60

THE MASTER JOB

61

Unit Test

Deploy to QA

Acceptance tests

Deploy to Production

Production Smoke Tests

Code Coverage

THE APPLICATION

62

63

CONNECT CODE WITH GITHUB

64

UNIT TESTS

65

RUN UNIT TESTS LOCALLY

Run from eclipse

Run from maven

66

67

UNIT TEST COVERAGE - COBERTURA

68

69

SONAR: CODE ANALYSIS / CODE QUALITY

70

71

WE ARE READY FOR THE NEXT STEP

ADD CI JENKINS

SET UP JENKINS JOBS

-  Master Job

-  Run unit tests

-  Deploy to QA

-  Run E2E tests

-  Deploy to PROD

-  Run PROD smoke tests

72

MASTER JOB

73

JOB: UNIT TESTS (1)

74

JOB: UNIT TEST (2)

75

JOB: DEPLOY TO QA

76

JOB: INTEGRATION TESTS

77

JOB: DEPLOY TO PRODUCTION

78

JOB: PRODUCTION SMOKE TESTS

79

JOB: SONAR

80

JOB: COBERTURA

81

PIPELINE: HAPPY PATH

82

PIPELINE: UNHAPPY PATH

83

THANK YOU!

84

top related