In an ever more competitive marketplace, organizations have turned to Agile and DevOps practices to deliver software innovations to market more quickly and with high quality. Across industries, companies are making heavy investments in tools and process improvements around automated build, test, continuous integration and delivery, and release automation and orchestration. However, despite these investments, many organizations are still struggling to bring the necessary speed and quality to their software delivery. In many cases, this is because Agile and DevOps improvements have not been applied to the entire software stack and are often limited to application code delivery. This webinar will explore the transformation that Colonial Life made in bringing DevOps to the entire software stack. Specifically, beyond automating and accelerating the validation and delivery of application code, this webinar will focus on the critical role that data and the database play in modern software delivery and the tools and processes that can bring the same automation to database code. After this webinar, you will understand: * What holds organizations back despite an Agile application development process * The benefits of automating the validation and deployment of database changes * A template for bringing DevOps to the entire software stack

1. 1
1
DevOps for the Full Stack
Colette Casey
Technical Architect – Unum/Colonial Life
July 10th, 2018

2. 2
2
§ Hold a bachelors degree in Computer Science
§ 20+ years of IT experience
§ Developer for 17+ years
§ Started with Mainframe (assembler and COBOL)
§ Moved to VB, ASP and COM+
§ Then to .NET (C#)
§ Been with Colonial (a Unum affiliate) for a total
of 8 years
§ 5 in my most recent stint
Hello, I’m Colette

3. 3
3
§ In a technical architect role
§ Responsible for architecture of ~32
applications and ~5 databases
§ Working on domain and solution
architecture for a MS D365
implementation
§ Foster/promote agile development
practices and DevOps amongst our
scrum teams
Currently…

4. 4
4
How Application Releases Used to Work at Colonial Life…
# What Happens:
1 Developer codes and unit test locally, check-in to TFVC, version and label in TFVC
2 Deployment engineer pulls code from TFVC, manually initiates a build via Visual Build Pro on the build box
3 Deployment engineer manually initiates a copy of DLLs from build box to Dev server(s), DBAs manually deploy SQL scripts,
developers manually performed testing in the environment to validate the deployment
4 After passing Dev testing, Deployment engineer manually initiates a copy of DLLs from Dev server(s) to Acpt server(s), DBAs
manually apply SQL Scripts, QA manually performed functional and regression testing
5 After passing QA testing, Deployment engineer manually creates a backup, manually initiates a copy of DLLs from Acpt (UAT)
server(s) to production, DBAs manually apply SQL Scripts
Local Source
Code
Visual
Build Pro
Visual
Build Pro
Build
Box
Dev
(DEV)
Acpt
(UAT)
Visual
Build Pro
Visual
Build Pro
Prod
(PROD)
Our Stack:
• .NET
• IIS
• SQL Server
• VMWare
1 2 3 4 5

5. 5
5
How Database Releases Used to Work at Colonial Life…
• Creates DDL/DML
• VS or SSMS
• Verified locally
• Checks into TFS (TFVC)
Dev DA
• Reviews changes
• Makes suggestions
related to indexes, and
table/column naming
conventions
DB Dev
• Review for standards
• Make necessary changes
based on standards
• Pull scripts from TFS,
package (zip), apply to
Pre-Dev database using
Visual Build Pro
DBA
• Unpacks zip file and copies
to server
• Manually performs backups
• Manually starts VS Build
Pro script to execute scripts
• If failures, manually
corrects and restarts VS
Build Pro script

6. 6
6
§ Code: Long checklist that
had to be manually
executed. Steps
sometimes missed or left
incomplete.
§ Database: Entirely
separate process and
group of people
responsible for manual
deployment steps. Steps
sometimes missed or left
incomplete.
Issues with Old Software Deployment Process…
§ Code: No versioning. No
packaged artifact. Hard to
track currently deployed
version. Deployments
were not repeatable.
§ Database: No versioning.
No packaged artifact.
Hard to track database
scripts for a given
deployment.
§ Multiple manual hand-offs
between groups in the
enterprise
§ Dev Team, Deployment
Engineers, DBAs,
QA/Test, etc.
RISKY UNRELIABLE SLOW & INEFFICIENT

7. 7
7
§ Agile Transformation
§ Company began an Agile transformation at the beginning of 2016
§ Business Delivery
§ With Agile transformation, business wanted to be able to release more
frequently
§ Provide business value to consumer quicker, with quality and reliability
§ Development Time
§ Give Scrum teams more time back for feature delivery
Why change…

8. 8
8
A Modern Pipeline – Tools for Full-Stack
DevOps

9. 9
9
§ Agile Central: Backlog Management
§ Visual Studio: Development IDE
§ SSMS: SQL Development
§ TFS (TFVC or GIT): Source Code Management
§ SonarQube: Code analysis
§ Jenkins: Continuous Integration
§ JFrog Artifactory: Artifact Repository
§ Octopus Deploy: Automated Deployment
§ Datical: Database Release Automation
Tools for Agile Development and Release

10. 10
10
Pull from TFS
Build app
code
Datical
packaging
Unit test app
code
App artifact Deploy to
DEV
Validate full
stack
Deploy to
DEV
DB artifact
Full-Stack Modern Continuous Integration Process…
Jenkins Process
App
code
DB
code
Notify
team;
Repeat
DEV

11. 11
11
§ Promoting code through environments
(beyond DEV)
§ Jenkins and/or Octopus Deploy
§ Deployment Engineer can either:
§ Kick-off a Jenkins job supplying
parameters for environment and package
version
§ Use Octopus Deploy UI to deploy
particular package version
§ This applies to both code and database
packages
§ Process is now completely automated
and repeatable
Modern Continuous Deployment Process…
Acceptance
Tests
Deploy to
Stage
autoUnit
Tests
autoBuild auto
C O N T I N U O U S I N T E G R A T I O N
Acceptance
Tests
Deploy to
Production
manualDeploy to
Stage
autoUnit
Tests
autoBuild auto
C O N T I N U O U S D E L I V E R Y
Acceptance
Tests
Deploy to
Production
autoDeploy to
Stage
autoUnit
Tests
autoBuild auto
C O N T I N U O U S D E P L O Y M E N T

12. 12
12
Impact of Modernizing the Pipeline (aka Full-
Stack DevOps)

13. 13
13
Improvements realized (release cycle)…
Dev Build Test Release
Dev Build Test Release
4-5 Month Release Cycle
3 Hour Build
1 Deploy per 10 Days
~1.5 Month Release Cycle
1 Hour Build
Daily Deploy
Release Cycle Improvements:
• 3x Build
• 10x Deployment
• ~3x Release Cycle

14. 14
14
Improvements realized (handoff elimination)
Dev
Build &
Deploy to Dev
Acceptance Test Release
Build
&
Deploy
Acceptance
Test
Release
2-3 daily interations
Dev
Handoff Eliminated
Automatic Build & Deploy
Average savings of 5-10 hours per build & deploy
(from Dev through Acceptance)
Hand-
Off
Hand-
Off
2-4 hours 2-4 hours
2-3 hours per build
Hand-
Off
2-4 hours
Hand-
Off

15. 15
15
AFTER: (7) Automated Releases per Year
BEFORE: (3) Manual Releases per Year
Improvements Realized (# of releases)
Release
1
Release
2
Release
3
Release
4
Release
5
Release
6
Release
7
Release
1
Release
2
Release
3

16. 16
16
Key Learnings and Recommendations

17. 17
17
§ Evaluate what you can do with the applications you have
§ First: Think about just doing automated build/deploy, possibly add other
automation to the pipeline (such as test) and then go back to think about
architecture. (shorter term effort with benefits realized faster)
§ Next: Evaluate what it takes to re-architect? (longer term effort with benefits
realized later)
§ Even for greenfield apps:
§ Think through the pipeline before you start development!
Strategy for Modernizing Applications

18. 18
18
§ What types of tools work best (related to the stack you use)
§ List out tasks and map tools to the tasks
§ Tools can depend on the stack you are using (Java, .NET, etc.), but there are
some agnostic tools
§ Jenkins and Artifactory are agnostic
§ Artifactory: nobody had previously managed a binary repo
§ Datical is agnostic to common DBMS platforms in the enterprise
§ Two types:
§ Automate a task that has been happening
§ Net new tasks/processes/activities (Artifactory)
Advice on Tools for DevOps

19. 19
19
§ Do you have in-house applications that are very data-heavy or
otherwise coupled to a database?
§ Ex: We had 900 database scripts as part of a single release. Can’t do
DevOps without automated versioning, validation, and deployment of
these scripts
§ When you have apps that are highly dependent on the database
– your data has to go with your code deployment. Otherwise
things will get out of sync only slowing the pipeline.
Database Best-Practice

20. 20
20
§ Going to expand across the
enterprise
§ Figure out a good set of best
practices and got familiar with
tools
§ Start by bringing build, release,
and test automation first to all
pipelines to start releasing
faster
Next Steps
§ Going to streamline pipeline
creation and management
§ Script out the pipeline instead
of manually defining/configuring
so we can version and backup
the pipeline itself. It’s pipeline
as code!
§ Evaluate what systems need
database release automation
§ Not all apps consistently
include database changes
1 32

21. 21
21
Questions?
Past Present
3 Manual Releases a Year 7 Automated Releases a Year