This document discusses best practices for software development teams to continuously deliver and maintain successful products beyond initial release. It emphasizes establishing practices like continuous integration, deployment automation, configuration management, and ensuring code quality and maintainability through techniques like testing, code reviews and style guidelines. The goal is to keep developers focused on continuously delivering business value while facilitating collaboration between development and operations teams.
4. WORKING FOR
ResearchGate gives science back to the people who make it happen.
We help researchers build reputation and accelerate scientific
progress.
On their terms.
6. AGENDA
We will look at what is necessarily to keep shipping a successful
product beyond its initial release and what role we developers should
be playing in this.
Development practices
Planning and Communication
Deployment and Operations
YMMV
8. 10 YEARS AGO
HOW I GOT HOOKED ON CREATING STUFF ON THE
WEB
Creating things is awesome
It was super easy and fun
9. 10 YEARS AGO
CUSTOMERS
"We want a website!"
"Can you fix this little thing please?"
"What do you mean you're already done?"
10. 10 YEARS AGO
WHAT IDIDN'T KNOW BACK THEN
Things got bigger, a lot bigger
"Web applications" vs. "Websites"
Maintaining things was really hard
It's about more than just programming
13. MY FIRST WEB APPLICATION
6 devs, growing to 20
Big code base
Quite some data, for the time
This talk is about everything we had to take care of, and more
15. LET'S SHIP IT!
THINGSTO TAKE CARE OF
Fulfilling current requirements
Figuring out what to do next
Delivery and Operations
ASK QUESTIONS AT ANY TIME!
16. WE'RE DEVELOPERS
Let's start with us!
We get paid to do what we love
Most of us started because we where fascinated by programming
But what is our job?
17. OUR JOB IS TO DELIVER
Get things done
Give good estimates
Ask the right questions
Keep doing that
Don't slow down
Keep our promises
18. THE COST OF HAVING USFOLKSAROUND
German numbers, YMMV €, Approximations
Salary: ~50k a year 50.000€ / Year
Adding non-wage labor cost 80.000€ / Year
Office space, water, hardware, coffee,
plants, cleaning, travels, training
100.000€ / Year
Weekends, holidays, vacation, etc:
We works 220 days a year.
455€ / day
"Classic" 8 hour work day 55 Bucks per Hour!
We are expected to contribute over 100.000 Bucks in business value
per year!
19. HOW?
Evaluate everything you're doing by a simple question:
“Does the practice in question help us to continuously
ship what our business needs to succeed?”
21. THE MOST BASIC THING:
Separate the web-glue from the business logic.
Keep templates stupid
Have services owning the logic for manipulation of business entities
Hide the data access behind a layer that you can maintain
individually
23. COMPOSITION OVER INHERITANCE
Don't inherit from things if you can just use them.
http://c2.com/cgi/wiki?CompositionInsteadOfInheritance
http://en.wikipedia.org/wiki/Compositionoverinheritance
24. DEPENDENCYINJECTION
This goes for you code base as well as for your whole Company.
Allows for quick and easy reuse of small components
If wiring is to hard people will copy/paste instead
Can be achieved in many ways. Pick one that works for you
http://pimple.sensiolabs.org/
http://symfony.com/doc/current/components/dependency_injection/index.h
https://github.com/researchgate/injektor
“In the end - everything is a wiring problem.”
25. REUSING CODE
The Dependency Manager for PHP
As easy as committing everything to your SCM. But with care free
autoloading.
26. TESTING
The art of making sure that you notice failures before your customers
do.
Testing exist to give you confidence when moving forward.
27. THE FASTEST THING YOUCAN DO
Staging server
Testing your builds
All without even touching Behat or PHPUnit
hits=`curl -s staging.project.com | grep 'Login:' | wc -l`;
test $hits -eq 1 || echo "Frontpage error!"
data="login=test&passwort=secure&csrf="$csrfToken
url="staging.project.com"
hits=`curl -X POST -d $data $url | grep 'Hello, testuser' | wc -l`;
test $hits -eq 1 || echo "Login error!"
28. OTHER DEPARTMENTSDON'T CARE ABOUT UNIT TESTING
Nor should they!
Your fellow developers on the other hand ... :)
“The mechanic fixing your car doesn't ask you what
song she should listen to while performing the task.”
30. BUT TESTING ISHAAAARD
Writing proper code is hard
The harder it is to use the code in question, the harder is writing tests
for it
Complex tests means the code is to complex. Break it down.
If anything: Mocking is hard(-ish).
Phake is your friend:
http://phake.digitalsandwich.com/docs/html/
FBMock: Mocking for grown ups:
https://github.com/facebook/FBMock
The PHPUnit mocking API is still good enough.
31. TDD
Writing tests can feel like extra work if you are rethinking an already
solved problem
TDD offers a way to first think about the problem, the interface and
the interactions and then filling in the details step by step until you are
done with the bigger picture.
32. QUICK WINSWITH BEHAT
Web tests help you detect a big amount of wiring issues with little
effort
Before growing to many of them consider maintenance
"Full stack testing" will allow you to ship with great confidence
34. CODE REVIEW
There are a lot of ways to go about this
Small teams can use commit based review
When feature branching the merge back is a natural point
Internal coding Dojo
Pair programming
Send emails when important changes occur
The main point of these ideas is to make sure everyone has a good
understanding of how common things are solved and to keep people
communicating.
35. CODING GUIDELINES
A collection for formatting and structure rules so that everyone can
easily find their way around and produce uniform code.
Just create the rule set fitting your practices
Adapt when there is pain
Don't over analyze. Just do it
PHP CodeSniffer:
http://pear.php.net/package/PHP_CodeSniffer
http://pear.php.net/manual/en/package.php.php-
codesniffer.annotated-ruleset.php
http://edorian.github.io/php-coding-standard-generator/#phpcs
“Coding rules:
It doesn't matter what they are - as long as you have
them.”
36. COMPLEXITYGUIDELINES
Similar to a coding standard but focusing on hunting down potential
problems within your source code
Possible bugs
Suboptimal code
Overcomplicated expressions
Unused parameters, methods, properties
PHP MessDetector:
http://phpmd.org/
http://phpmd.org/rules/
http://edorian.github.io/php-coding-standard-generator/#phpmd
37. CONTINUOUS DEVELOPMENT PACE
"Done" means there is nothing left to clean up
Every once in a while you plan time to throw away things
"Having a clean slate" is an attitude and a culture
“There are only two hard problems in Computer
Science: cache invalidation, naming things, and off-
by-one errors.”
38. CI
Have a automated way of checking all the things you agreed on
Run web and unit tests
Ensure coding guidelines
Ensure complexity guidelines
Keep the project deploying :)
Tools:
http://jenkins-ci.org
http://jenkins-php.org
http://www.sonarsource.org
40. SHIPPING REDUCES COMPLEXITY
"Did we already implement this a month ago?"
"That bug you just reported was fixed 2 weeks ago. Just not
deployed yet"
Shipping let's you discover what doesn't work before you spend too
much time on it.
41. PLANNING CAN BE A BIG MINDSET CHANGE
“Nobody told me my job involved talking to... people”
42. ASSUME COMPETENCE
Work with the basic mind set that other people are at least as good in
their job as you are in yours.
If they tell you to do "stupid" things find out what they want to
achieve
Company "vision" is a big here
Just know what you want to get done and work together
43. HAVING EVERYONE INVOLVED
Getting everyone in the same boat and working towards a common
goal will speed you up like nothing else every will.
Product
Design
Copyrighting
Engineering
""Upper management""
If you can ensure that everyone was involved somewhere in the loop
you spend way less time on re-discussing and avoid confusion.
45. TOOLING
Tooling is needed when people can't get the information they need
A wall with Post'it notes and a stack of story cards might be all you
need
When working remote spend time on making it look beautiful so that
people look at it
https://trello.com/
$millionOfOtherProducts
46. BUGS
Technical errors
Communication errors (and forgotten features)
Fix the technical issues quickly to reduce complexity
Don't build "bug management".
But at a certain size you need someone to dispatch bugs to safe
everyone time
47. STATS
State are awesome!
Knowing what your users actually do with your software is valuable
Seeing them use the new thing you build is - like - the best ever(tm).
StatsD: https://github.com/etsy/statsd/
Graphite: http://graphite.wikidot.com/
50. DEVOPS
Talking to the people getting up at night so you don't have to.
Your SysAdmins care. A lot!
It's your job to figure out a way to constantly deploy without
breaking things
Automation helps avoiding errors
51. BUILD AND DEPLOYMENT TOOLING
A collection of scripts that gets you from "source code" to "running in
production".
Create a build
Can be done in Jenkins. Still keep it in a script and let Jenkins run
it.
Run unit tests
Run integration, functional tests
Report on coding/complexity metrics
Once you are confident that things are going to go well
Deploy the build to a staging environment
Run web tests
Deploy to production
Rollback when really really needed
That's it. No magic - Just detail work.
52. HOW TO GET THAT SCRIPT?
It doesn't matter what language you write that tooling in. There is no
generic answer.
Chances are there is going to be a lot of BASH in it.
Whatever calls your BASH script isn't all that important
Ant
More custom BASH
Ant Build Commons
SF2 CLI commands
Whatever works. As long as you can maintain it and it's stable.
Don't over-engineer. You'll iterate a lot over this.
54. PROVISIONING
Getting servers and development environments in a known state
Having the SAME versions on dev and prod is invaluable.
The only documentation that gets always updated is the code.
Being able to recreate servers safes a lot of hassle.
Think about your firewalls :)
Having a virtual machine per project keeps you sane
http://www.vagrantup.com/
https://puppetlabs.com/
http://www.opscode.com/chef/
55. CONFIGURATION MANAGEMENT
Any solution will require close collaboration with the folks running the
production boxes or lead to hassle.
Config files in puppet/chef
Configs for all systems in the SCM and only reading in environments
Setting systems up in a way that they always look the same
56. DATA MIGRATIONS
This questions comes up a lot when talking about automation. There is
no easy answer.
Very specific to your project and environment
Usually not possible to have downtime while data is migrated
Don't throw away DB columns when you change the code. Add new
ones and clean up later when you are sure.