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.

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. wojciech@sznapka.pl
    @twitter twitter.com/sznapka
    @github github.com/wowo
    

    View Slide

85. Dołącz do nas!
    

    View Slide