Smart development environments

489 views

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
489
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Smart development environments

  1. 1. Smart development environments
  2. 2. Wojciech Sznapka PHPCon Pl Szczyrk 27.10.2013
  3. 3. Cześć! :)
  4. 4. Hanys ze Ślůnska wito Wos pierońsko piyknie
  5. 5. Since 2006 regularly in a teams of developers
  6. 6. Loves software craftsmanship, sophisticated architectures, Big Data and automation
  7. 7. Why a development environment needs care?
  8. 8. Because mess frustrates people
  9. 9. And repetitions leads to routine and are always error prone
  10. 10. Automation is always better than written process
  11. 11. The version control
  12. 12. GitHub private repositories
  13. 13. Every team member has his own fork
  14. 14. He creates a feature branch related to the User Story from Jira, he is working on
  15. 15. He works on his own machine
  16. 16. After a series of commits to his feature branch he opens a pull request
  17. 17. Other devs review the code and make comments
  18. 18. Pro Tip: smaller pull request are easier to review and maintain
  19. 19. Developer fixes things and pushes again
  20. 20. The responsible person merges pull request into develop branch
  21. 21. The code metrics
  22. 22. Most of new projects are started based on Symfony XSolve Edition
  23. 23. It contains standard build.xml for Ant
  24. 24. There are around 28 targets
  25. 25. Most important are:
  26. 26. Most important are: »» build - used to deploy
  27. 27. Most important are: »» build - used to deploy »» ci - run on Jenkins
  28. 28. 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
  29. 29. 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
  30. 30. Code metrics are collected by Jenkins and available there
  31. 31. Builds
  32. 32. We build every change in develop branch
  33. 33. Also we build every project in the morning to see if passing time hasn’t affected the code :-)
  34. 34. The third build goes for Pull Requests
  35. 35. We’ve integrated Jenkins GitHub PR Builder
  36. 36. It runs tests and checks if code metrics warnings don’t exceed thresholds
  37. 37. This mechanisms helps us to not watch for code style or obvious things during code reviews, but to focus on what’s important
  38. 38. Deployments
  39. 39. A standard servers structure:
  40. 40. A standard servers structure: »» development
  41. 41. A standard servers structure: »» development »» CI server
  42. 42. A standard servers structure: »» development »» CI server »» test server
  43. 43. A standard servers structure: »» development »» CI server »» test server »» stagagging (A.K.A. Preview) server
  44. 44. A standard servers structure: »» development »» CI server »» test server »» stagagging (A.K.A. Preview) server »» production
  45. 45. We use launcher to update application on test and stagging server
  46. 46. Launcher is our Silex based application that launches ant tasks, triggered by github hook
  47. 47. It updates test env for every change...
  48. 48. ... and staging for every new tag
  49. 49. Communication
  50. 50. We use HipChat
  51. 51. It has a great and simple API
  52. 52. And plenty of tools has built-in integration
  53. 53. And plenty of tools has built-in integration »» GitHub
  54. 54. And plenty of tools has built-in integration »» GitHub »» Jira
  55. 55. And plenty of tools has built-in integration »» GitHub »» Jira »» Jenkins
  56. 56. And plenty of tools has built-in integration »» GitHub »» Jira »» Jenkins »» New Relic
  57. 57. And plenty of tools has built-in integration »» GitHub »» Jira »» Jenkins »» New Relic »» Zabbix
  58. 58. Also our internal tools uses HipChat API to notify important facts
  59. 59. Of course we have github, jira, jenkins emails notifications
  60. 60. Extras
  61. 61. Github-metrics
  62. 62. It counts pull requests and commits per developer across all repos and pushes it to HipChat every morning at 10:00
  63. 63. XSolve Developers Metrics
  64. 64. Harvesters Jenkins API to get number of violations (or fixes) for every developer
  65. 65. Summary
  66. 66. It requires a lot of effort to put all those tools together
  67. 67. Even more work is required to maintain and keeps it running
  68. 68. But after some time it works gloriously
  69. 69. Teams don’t waste time on non-programming work
  70. 70. It’s way easier to introduce new team members
  71. 71. And you have a lot more time to think about solving world’s problems
  72. 72. Thank you
  73. 73. wojciech@sznapka.pl @twitter twitter.com/sznapka @github github.com/wowo
  74. 74. Dołącz do nas!

×