Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Getting Faster, Continuous Lifecycle 2013
Search
Oliver Wehrens
November 11, 2013
Technology
2
5.1k
Getting Faster, Continuous Lifecycle 2013
How we got from a release every six month to daily releases.
Oliver Wehrens
November 11, 2013
Tweet
Share
More Decks by Oliver Wehrens
See All by Oliver Wehrens
Service Discovery For Machines And Humans - OOP conference 2017
owehrens
0
10k
How not to lose your mind with too many microservices - Architecture Gathering 2016
owehrens
3
270
How not to lose your mind with too many microservices - BedCon 2016
owehrens
1
690
Entwicklung verteilter Systeme (The Architecture Gathering 2015)
owehrens
1
110
Entwicklung verteilter Systeme - Herausforderungen nicht nur für die Architektur, BedCon 2015
owehrens
0
2.2k
Wider den Monolith - Am Ende wird alles gut. WJAX 2014.
owehrens
1
3.6k
Provisioning from Development to Production, BedCon 2013
owehrens
0
2.9k
Other Decks in Technology
See All in Technology
OSSコミットしてZennの課題を解決した話
dyoshikawa1993
0
150
Github Actions 로 Android 팀의 효율성 극대화
hadonghyun
0
160
データベース研修 DB基礎【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
210
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
470
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
180
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
Datadog Cloud SIEMを使ってAWS環境の脅威を可視化した話/lifeistech-datadog-cloud-siem
gidajun
0
480
Luupの開発組織におけるインシデントマネジメントの変遷 ver.RoadtoSRENEXT2024
grimoh
1
270
AWSでRAGを作る法方
sonoda_mj
1
140
What is DRE? - Road to SRE NEXT@広島
chanyou0311
3
620
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
AIエージェントを現場に導入する目線とは
masahiro_nishimi
1
1.5k
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
90
47k
4 Signs Your Business is Dying
shpigford
178
21k
Six Lessons from altMBA
skipperchong
24
3.2k
KATA
mclloyd
20
13k
Facilitating Awesome Meetings
lara
46
5.8k
Principles of Awesome APIs and How to Build Them.
keavy
124
16k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.8k
Building an army of robots
kneath
301
42k
GitHub's CSS Performance
jonrohan
1026
450k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
44
4.7k
What's in a price? How to price your products and services
michaelherold
239
11k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
20
7.2k
Transcript
getting faster How we got from a release every six
month TO daily releases Continuos Lifecycle 11.11.2013
AndrÉ von deetzen @vdandre Oliver Wehrens @owehrens
Migration what’s next Status Agenda one stack Lessons learned
Status How we started
150 DEV / QA / OPS
> 100 SOURCE REPOSITORIES
1 RELEASE EVERY SIX MONTH
1 TEAM TO RELEASE & DELIVER
1 DEPLOYMENT IN PRODUCTION
Technology stack PHP JAVA RUBY LINUX puppet tomcat C++ C
SQL perl python jboss httpd
development & production different installer other os bare metal vs
virtualisation different puppet versions other ways of monitoring
Wait whaT? How did we GET here? Features, Features, Features
faster, faster, faster (not really) solved the scaling problem upfront
Transition What did we do?
Time to market Analysis 6 Months 2 Weeks daily
Squeeze The existing
Automate as much as we can
From 6 to 3 Months
scrum no more waterfall
From 3 to 1 Month
optimize agile + automation
From 1 Month to 2 weeks
Still a monolith
Still nightly deployments
New Functionality?
We can do better!
One Stack (with variations)
new platform simplify unify loosely coupled daytime deployment disaster recovery
!
Three areas to change
Architecture (many) small services stateless independently deployable stable interfaces
Deployment MAKE RPM NOT WAR PUPPET with HIERA automatic vm
setup
Workflow staging build chain empower teaMs infrastructure
create virtual machine install yum, rpm, centos reboot smoketest lifecycle
configure puppet operate €€€
technology stack JVM Tomcat Centos 6 YUM & RPM Puppet
3 REST
deployment pipeline development release candidate certified release reference production
started with one new service and one team
Approach became very popular
existing services ? anti corruption Layer refactoring rewrite (better not
do it)
> 200 Deployments STAGED TO PRE-PRODUCTION ON OUR BEST DAY
IN 2013
2014 What’s next?
Automate all the things! Puppet for network components Automate firewalls
Increase visibility Infrastructure self service evaluate container based approach instead of VMs
lessons learned
Same environment & Tools Everywhere is essential
don’t get too fast, we could not deploy every delivery
had not enough Capacity for VMs in Development
Rewrite = Long time no roi
Spreading Knowledge can’t be fast enough
need to recreate any Machine automatically
Questions ? And yes, we’re hiring too! come talk to
us.
Thanks for your attention!