My slides from my talk at AgileCE in Cracow 2011 about the deployment process, the roles of developers and admins in the products lifecycle with practical suggestions.
2. Is production deploy part of DONE?
Has your customer ever been afraid of updates?
Do you have:
continuous-integration?
fully-automated-deployment?
continuous-deployment?
who is NOT having integration and/or unit tests?
anixe
3. This is deployment -manual, hard, not-repeatable
without the team, without coordination
Tough cowboy thinks he can handle it all
deploy once the build has succeeded
or midnight deploy
If cow runs away
cowboy runs after cow and fixes problem
you can patch cows on production (pasture)
cows are kind of self-organizing - servers are not
deployment process
anixe
4. This is how we started a couple of
anti-patterns years ago!
cowboy deployment - manually
driving the cattle to the pastures
ad-hoc releases
production patching
service monolith
lack of automation
• AdHoc Release – Devs would deploy as soon as they made quick fixes to the application.
• Production Patching – Sysadmins change configs and other parts directly on production, nobody knows what they changed
• Service Monolith – the apps are not modular enough or not modular the way and nobody understood how they work together.
• Lack of Automation – the whole deploy process was done manually, every time!
anixe
5. separation of concerns
Technology
Operations deployment
web applications
infrastructure
versioning
software architecture
Software QA
shared applications Development technical analysis
24x7 support
research & development
systems & app administration
QA
what we did? what many do!
we split! Both Devs and Ops, from their perspective, want the best for the business.
Only, optimizing any subsystem without context, leads to the destabilization
of the system as a whole, de facto decreasing overall performance.
anixe
6. conflict of interests
Software Technology
Development Operations
no contact with
customer change preservation
new features release is risk
release often availability
stability
reliability
anixe
7. anti-patterns
ad-hoc releases
production patching
service monolith
lack of automation
• AdHoc Release – Devs would deploy as soon as they made quick fixes to the application.
• Production Patching – Sysadmins change configs and other parts directly on production, nobody knows what they changed
• Service Monolith – the apps are not modular enough or not modular the way and nobody understood how they work together.
• Lack of Automation – the whole deploy process was done manually, every time!
anixe
8. anti-patterns
ad-hoc releases
production patching
service monolith
lack of automation
over the wall deployment
• AdHoc Release – Devs would deploy as soon as they made quick fixes to the application.
• Production Patching – Sysadmins change configs and other parts directly on production, nobody knows what they changed
• Service Monolith – the apps are not modular enough or not modular the way and nobody understood how they work together.
• Lack of Automation – the whole deploy process was done manually, every time!
anixe
9. solution 1: devops
new movement
sysadmin who can program
Software Technology
Development Operations
devops = sysadmins with
coding knowledge
pros cons
+ ops can lookup code - silos
+ ops can automate platform install/deploy - dev not responsible for production
+ ops can better understand app
+ ops can write tests
anixe
10. solution 2: no-ops
Software
Development
&
Technology
Operations
one really cross-functional
team
pros cons
+ all understand app - 24x7 support
+ common responsibility - dev must know hardware/infrastructure
- dev must know all customer configs
anixe
11. solution 3: cloud
deployment
app administration
infrastructure
web applications Software Technology technical analysis
versioning
software architecture Development Operations 24x7 support
systems administration
shared applications
research & development
pros cons
+ internal/outsource infrastructure doesn’t - silos
matter - support difficult, lack of knowledge of app
+ devs responsible for production done
anixe
12. how far have we come?
our current solution: cloud
windows linux
devs build, test and write deploy scripts devs build, test and deploy
ops run deploy scripts devs deploy via scripts
dbs do db migrations via script scripts do db migrations
devs write app management scripts
anixe
14. thanks!
Piotr Żołnierek
@pzol
speakerrate.com/pzol
pzol.agirei.com/holistic-devployment
anixe
Hinweis der Redaktion
-CTO @anixe - cool stuff \n- tuesdays, thursdays also CEO\n- develop in .net, ruby\n
- great software need to get it to production\n- devs become quicker in building, but cannot release as often as they want, \n- ops might have a different cycle (customer related), shared resources, own department\n- ops rarely automate, newest trend, install on one VM and clone\n- hardening sprints? separate operations/admin departments? (creates waterfall)\n- limited access to production, PCI compliancy\n- we have cross-functional teams, but without including admins / infrastructure\n
- we were a cool startup, only cool developers\n- we have been struggling with this problem for a long while\n- cowboy deployment - tough - confident - guy who thinks he can do it all\n- no automated testing originally\n- all manual work all the time\n- builds a great new feature and uploads it directly in to production (manually)\n- is manual releases, at the will of the cowboy (deployer) - no coordination, no qa \n