Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Smart development environments

Smart development environments

The work of development team is very sophisticated and fragile process. Every boring, repeatable and error prone factor lowers team's velocity. This is why we invested a time, which weren't related to programming into process automation.
Smart development environments are based mainly on Open Source tools. The core is private GitHub repository. It's responsible for code increments, code reviews and releases versioning. Additionaly there is Jenkins, Ant, PHP QA tools. Furthermore code review process has been automated, as well as an application deployments, notifications and progress measurement.
The set works perfectly with Symfony2, Silex and other PHP applications.
Presentation will contain real life examples, with configurations and code snippets.

Wojciech Sznapka

October 27, 2013
Tweet

More Decks by Wojciech Sznapka

Other Decks in Programming

Transcript

  1. Smart
    development
    environments

    View Slide

  2. Szczyrk 27.10.2013
    Wojciech Sznapka
    PHPCon Pl

    View Slide

  3. View Slide

  4. View Slide

  5. Cześć!
    :)

    View Slide

  6. Hanys
    ze Ślůnska wito Wos
    pierońsko piyknie

    View Slide

  7. Since 2006 regularly
    in a teams of developers

    View Slide

  8. Loves
    software craftsmanship,
    sophisticated architectures,
    Big Data and automation

    View Slide

  9. Why a development
    environment
    needs care?

    View Slide

  10. Because mess
    frustrates people

    View Slide

  11. And repetitions leads
    to routine and are always
    error prone

    View Slide

  12. Automation is always better
    than written process

    View Slide

  13. The version
    control

    View Slide

  14. GitHub private
    repositories

    View Slide

  15. View Slide

  16. Every team member
    has his own fork

    View Slide

  17. He creates a feature branch
    related to the User Story from
    Jira, he is working on

    View Slide

  18. He works on his
    own machine

    View Slide

  19. View Slide

  20. After a series of commits to
    his feature branch he opens
    a pull request

    View Slide

  21. Other devs
    review the code
    and make comments

    View Slide

  22. Pro Tip:
    smaller pull request
    are easier to review
    and maintain

    View Slide

  23. Developer fixes things and
    pushes again

    View Slide

  24. The responsible person
    merges pull request into
    develop branch

    View Slide

  25. The code metrics

    View Slide

  26. Most of new projects
    are started based on Symfony
    XSolve Edition

    View Slide

  27. View Slide

  28. It contains standard build.xml
    for Ant

    View Slide

  29. There are around 28 targets

    View Slide

  30. Most important are:

    View Slide

  31. Most important are:
    »
    » build - used to deploy

    View Slide

  32. Most important are:
    »
    » build - used to deploy
    »
    » ci - run on Jenkins

    View Slide

  33. Most important are:
    »
    » build — used to deploy
    »
    » ci — run on Jenkins
    »
    » cli — runs code sniffer, mess detector,
    copy paste detector on CLI to check curremt
    status before committing

    View Slide

  34. Most important are:
    »
    » build — used to deploy
    »
    » ci — run on Jenkins
    »
    » cli — runs code sniffer, mess detector,
    copy paste detector on CLI to check curremt
    status before committing
    »
    » thresholds-check — to build PRs

    View Slide

  35. Code metrics
    are collected by Jenkins
    and available there

    View Slide

  36. Builds

    View Slide

  37. We build every change
    in develop branch

    View Slide

  38. Also we build every project
    in the morning to see
    if passing time hasn’t affected
    the code :-)

    View Slide

  39. The third build goes
    for Pull Requests

    View Slide

  40. We’ve integrated
    Jenkins GitHub PR Builder

    View Slide

  41. It runs tests
    and checks if code metrics
    warnings don’t exceed
    thresholds

    View Slide

  42. View Slide

  43. View Slide

  44. View Slide

  45. This mechanisms helps us
    to not watch for code style
    or obvious things during code
    reviews, but to focus on
    what’s important

    View Slide

  46. Deployments

    View Slide

  47. A standard servers structure:

    View Slide

  48. A standard servers structure:
    »
    » development

    View Slide

  49. A standard servers structure:
    »
    » development
    »
    » CI server

    View Slide

  50. A standard servers structure:
    »
    » development
    »
    » CI server
    »
    » test server

    View Slide

  51. A standard servers structure:
    »
    » development
    »
    » CI server
    »
    » test server
    »
    » stagagging (A.K.A. Preview) server

    View Slide

  52. A standard servers structure:
    »
    » development
    »
    » CI server
    »
    » test server
    »
    » stagagging (A.K.A. Preview) server
    »
    » production

    View Slide

  53. We use launcher
    to update application on test
    and stagging server

    View Slide

  54. Launcher is our Silex
    based application that
    launches ant tasks, triggered
    by github hook

    View Slide

  55. It updates test env for every
    change...

    View Slide

  56. ... and staging for every
    new tag

    View Slide

  57. Communication

    View Slide

  58. We use HipChat

    View Slide

  59. View Slide

  60. It has a great
    and simple API

    View Slide

  61. And plenty of tools
    has built-in integration

    View Slide

  62. And plenty of tools
    has built-in integration
    »
    » GitHub

    View Slide

  63. And plenty of tools
    has built-in integration
    »
    » GitHub
    »
    » Jira

    View Slide

  64. And plenty of tools
    has built-in integration
    »
    » GitHub
    »
    » Jira
    »
    » Jenkins

    View Slide

  65. And plenty of tools
    has built-in integration
    »
    » GitHub
    »
    » Jira
    »
    » Jenkins
    »
    » New Relic

    View Slide

  66. And plenty of tools
    has built-in integration
    »
    » GitHub
    »
    » Jira
    »
    » Jenkins
    »
    » New Relic
    »
    » Zabbix

    View Slide

  67. Also our internal tools
    uses HipChat API to notify
    important facts

    View Slide

  68. Of course we have
    github, jira, jenkins emails
    notifications

    View Slide

  69. Extras

    View Slide

  70. Github-metrics

    View Slide

  71. It counts pull requests
    and commits per developer
    across all repos and pushes it
    to HipChat every morning
    at 10:00

    View Slide

  72. View Slide

  73. XSolve Developers Metrics

    View Slide

  74. Harvesters Jenkins API
    to get number of violations
    (or fixes) for every developer

    View Slide

  75. View Slide

  76. Summary

    View Slide

  77. It requires a lot of
    effort to put all those tools
    together

    View Slide

  78. Even more work is required
    to maintain and keeps it
    running

    View Slide

  79. But after some time
    it works gloriously

    View Slide

  80. Teams don’t waste
    time on non-programming
    work

    View Slide

  81. It’s way easier
    to introduce new team
    members

    View Slide

  82. And you have a lot
    more time to think about
    solving world’s problems

    View Slide

  83. Thank you

    View Slide

  84. [email protected]
    @twitter twitter.com/sznapka
    @github github.com/wowo

    View Slide

  85. Dołącz do nas!

    View Slide