ალექსანდრე ნემსაძე - Release it სტუდენტური ჰაკათონი - http://macs.unihack.ge/ video: http://www.youtube.com/watch?v=bfcvJF7qCnw&feature=share&list=UUKyScn6UfDhuQ7UINKhyEfQ&index=2

1. Alexander Nemsadze
Software Developer

3. Typical Development Life Cycle
Conception
Initiation
Analysis/Req.Def.
Design
Development
Integ. Testing / QA
Deployment
Maintenance

4. Quality of Life

5. Quality of Life
 Release 1.0 is the beginning of your
software’s life, not the end of the
project.
 Your quality of life after Release 1.0
depends on choices you make long before
that vital milestone.

6. Quality of life degraded, what now?
Get fired!
Gain experience, learn lessons!

7. Stay happy

8. • Frequent server restarts
• Professional users
• Favorite browser
• No concurrent load on server
• Emulated integration points
• No financial risk in case of
malfunction
• Server is up for months
• All kind of users
• Different browsers (at least that you
have promised to support)
• Real load
• Real integration with external
services
• Negative financial impact
• No assumptions that something
won’t happen, if there is a tiny
chance it will definitely happen
Environment differences

9. Design Production-Ready System
 Choosing an appropriate technology
 Performance and capacity analysis
 Development team culture
 Architectural decisions
 Effective stress tests
 Deployment checklist
 Monitoring and effective incident investigation

10. Choosing an appropriate technology
 Investigate
 Evaluate
 Use cases
 Documentation
 Community
 Stability
 Tooling
 Storage
 Experience of your team, learning curve
 Use force
 Your early decisions make the biggest impact on the
eventual shape of your system.
 The earliest decisions you make can be the hardest
ones to reverse later.

11. Performance and capacity analysis
 Define capacity against system specificity
 Capacity can be maximum concurrent active sessions,
in case of public web site, until allowable response
time is not exceeded.
 Or it can be maximum transactions throughput in case
of financial transactions processing system.
 Any other thing or combination
 Memory usage analyses
 Horizontal scalability
 Hardware topology
 Maybe use some cloud vendor, that offers elastic
capacity service
 Server responsibilities

12. Development team culture
 Team members must understand and respect methodology
of project management, whether it’s agile, extreme or
whatever
 Note every detail
 Respect coding quality standard
 Unit tests are mandatory
 Integration test are desired for critical modules
 Don’t resolve an issue hoping that someone will test it for
you
 Worst and most annoying is returning back to issue that you
declared as resolved
 Make code reviews of each others code
 Refactor as many times as it is needed for your own
satisfaction looking at your own code.
 Log effectively
 Ask for advice, if you are not sure that you make it right

13. Architectural decisions
 Gather use cases and constraints before thinking
solution
 There are no straightforward rules or patterns
for success. All of this templates together with
experience just help to make correct decisions
 Do not confuse architecture with tools and
frameworks
 Design domain model from the performance and
reporting requirements point of view
 Rethink and refactor before it’s too late
 Avoid radical decisions when the milestone is
nearing
 Think pragmatic

14. Effective stress tests
 Try to build realistic environment
 Compose scenario of real world usage
 Simulate exceptional situations
 Analyze chains of failure
 Analyze increased memory usage impacts
 Analyze overall performance impacts
 Simulate integration points malfunctioning

15. Deployment checklist
 Make sure production parameters are set
correctly
 Check memory usage configuration
 Check database connection pool size
 Check thread pools configuration
 Check timeouts configuration
 Check logging configuration
 Check security configurations
 Other server configurations

16. Monitoring and effective incident investigation
Use monitoring tools and permanently analyze logs.
If you noted some suspected behavior, don’t
hesitate to react, before it will burst the overall
system.
After incident happened don’t immediately destroy
facts that would help you to investigate the issue.
If something happened once it will definitely
repeat.

17. Alexander Nemsadze
Software Developer