&Continuous Delivery

.Phase i

Continuous integration

lee Jen Wei 25 nov 2014

What is Continuous Integration & Continuous Delivery?

Continuous Integration

Continuous Delivery

Where are we?

We Are Here

Let’s begin the Continuous Journey . . .

Purpose

Automated deployment of source code to SIT, UAT, PRD On-premise servers AWS servers

Structured process to keep track and manage Application Change Requests Bug Fixes

Allows multiple developers to work together on same pieces of source codes Ease of development No overwriting / confusion of source codes Easy rollback

Focus on development work NOT deployment details

Features

Incremental code updates

Commit codes directly from SVN to Redmine issues

Release management by Issues

Email notification report on deployment details

Automatic SVN tagging for each successful releases

Publish builds events directly to Slack Channel

Tools

Deployment hooks and scripts Ruby Perl Shell scripts

Code Versioning Currently: CollabNet SubversionEdge v1.8.x Coming soon: Git

Issue tracking and release management Redmine v2.5.x

Jenkins Continuous Integration Numerous plugins

automated builds tools functional/load/performance testing tools reports and notifications integrations etc

An Overview.

Step 1: Create New Issue

Step 2: Commit Code

Changes

Step 3: Set Issue Status to

Promote Code

Step 4: Trigger Build &

Deploy

Step 6: Testing

Step 7: Auto Tagging

Backup

Step 5: Deploy Changes

to Servers

Continuous Delivery Process

Report Issue

Fix Issue

Deploy

Test

Close

User

Developers

Application Delivery Cycle Overview

Testers

Screen Captures

Redmine Issue Status Transitions

NewNew

Fix in ProgressFix in Progress

Pending Code Promotion SITPending Code Promotion SIT

Pending Code Promotion UATPending Code Promotion UAT

Pending Code Promotion PRDPending Code Promotion PRD

Ready for Retest UATReady for Retest UAT

Ready for Retest SITReady for Retest SIT

Ready for Retest PRDReady for Retest PRD

ResolvedResolved

deploy

deploy

deploy

Step 1 – Create a New Issue

Click on Create to create a new issue

Step 1 – Create a New Issue

Take note of the Issue #. It will be used later.

Step 2 – Commit Code Changes

Input the Issue # here i.e. “ref #26“

Step 2 – Commit Code Changes

Notice that the Status has changed from “New”

The SVN changes previously committed using the keyword “ref #” instructs the SVN Revision to be linked to the Redmine Issue

Step 2 – Commit Code Changes

Redmine allows you to view the details of the changes for the SVN Revision # 365

Step 2 – Commit Code Changes

Redmine Issues listing

Step 3 – Promote Code

Change the Status to Promote code changes in Issue #26 to the next environment. eg. SIT in this case.

Step 4 – Trigger Jenkins Build & Deploy

A build #166 is triggered in Jenkins when the Status is set to Pending Promote

Step 4 – Trigger Jenkins Build & Deploy

Details of the Build #166 can be seen viewed here

Automatically generated SVN commit message to the Branches deployed (eg. SIT)

Step 4 – Trigger Jenkins Build & Deploy

Jenkins will commit the changes in Build #166 to the Branches (eg. SIT) for delivery to the (eg. SIT) Servers

Step 5 – Deploy Changes to Server

A SSH connection inside the SIT Server

Changes are deployed to the actual Servers (eg. SIT) from the SVN Branches Repository (eg. SIT)

Step 5 – Deploy Changes to Server

An email notification of a successful deploymentof code changesto the relevant people in the Redmine Issue #26

Step 5 – Deploy Changes to Server

An example of an email notification of a error and failed deploymentto the relevant people in the Redmine Issue #10

Step 6 - Testing

Upon a successful Build or Deploymentthe Redmine Issue Status will be set to the “Ready for Retest” status

Step 7 – Auto Tagging Backup

In a successful Post-Build/Deployment, an automated Tagging will be committed under the SVN Repository folder:

-> tags -> last-successful -> environmentfor backups as well as a means for rollback of released code versions.

Step 8 – Publish Build Events to Slack

Optional: The system also allows Build events to be published to Slack channels of your choice.

Vision & Possibilities

1. To address the shortcoming of the more rigid 1st generation Mantis Deployment system.

2. To put many projects that are still deploying codes manually on a flexible, automated deployment system, as well as a systematic and trackable release management.

3. To relieve developers the laborious and unorganised manual work of accessing servers for code deployment and concentrate on more productive development work.

4. To improve the time-to-market of application features and bug fixes without sacrificing quality. More quality releases in a shorter time.

5. To give teams intending to embrace Agile, Scrum, Test-driven Development methodology, Automated Unit Testing, DevOps, etc, a tool to aid in their cause.

Vision & Possibilities

6. To provide mobile developments a tool for automated simulation testing of different devices.

7. To enable teams embracing AWS Cloud computing a systematic framework to fully automate the deployment of infrastructures and system administration operations.

8. To allow teams to make use of container tools like Docker to develop applications that are much more portable and efficient across deployment environments.

9. To provide for teams to eventually be able to fully automate the functional and performance testing of their apps that seamlessly integrates with release management.

10.To eventually be able to have a true Continuous Integration system that fully automates release management and delivery, hence saving time, improving productivity and efficiency with a peace of mind.