Lightning branches at RedMart (Js conf Asia 2014 Talk)
•Transferir como PPTX, PDF•
4 gostaram•1,456 visualizações
These are the slides from the talk given at JSConf Asia 2014 --- I will be talking about the "No talk all action" approach we take at RedMart for feature development. You’ll learn how we supercharge development and get code in production fast with an opinionated and automated development workflow. Hint: It’s a cocktail of Git, JS (of course), Chef, Devops & killing pointless meetings.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (7)
Semelhante a Lightning branches at RedMart (Js conf Asia 2014 Talk)
Semelhante a Lightning branches at RedMart (Js conf Asia 2014 Talk) (20)
Último
Último (20)
Lightning branches at RedMart (Js conf Asia 2014 Talk)
- 1. LIGHTNING BRANCHES HOW WE SUPERCHARGE DELIVERY OF FEATURES AT REDMART
- 2. Hi I’m @ringular work at @Redmartcom #frontend #devops
- 3. Getting Code to Production Fast
- 4. “No talk all action” Not this talk :(
- 5. Lesser Meetings More Productivity
- 6. Real World Development Workflow of a Scaling Startup
- 7. LIGHTNING BRANCHES HOW WE SUPERCHARGE DELIVERY OF FEATURES AT REDMART
- 11. What just happened? We just deployed a feature in production in a matter of minutes
- 12. Yes. It was staged..
- 13. Yes. It wasn’t really a feature..
- 14. but I’d say..
- 16. Specifically Cool for RedMart
- 18. BEAR WITH ME
- 23. More Developers working on More Features at the Same Time which results in lots of Merge Hells
- 24. More Developers working on More Features at the Same Time which results in lots of Merge Hells
- 25. More Developers working on More Features at the Same Time which results in lots of Merge Hells
- 26. More Developers working on More Features at the Same Time which results in lots of Merge Hells
- 28. Huddling behind developers doesn’t scale
- 29. Bring your laptop over every time? Nah
- 30. More Meetings Less Code :(
- 31. E = MC² Einstein’s Mass Energy Equation
- 32. E = C²/M E = Environment that developers love C = Code they write per day M = Meetings they attend per day
- 33. Recap Companies Scale Empower multiple features ( ↑ E ) More Code ( ↑ C ) Communicate in a Snap ( ↓ M )
- 34. Empower multiple features development Git flow
- 35. BEAR WITH ME
- 36. Git Flow - Quick Recap Master - Official Release History Release - Combined features Develop - Integration Branch Branching Model Hotfix/ - Bugfixes, based off master branch
- 37. Git Flow - Quick Recap Master - Official Release History Release - Combined features Develop - Integration Branch feature/* - Development of Features based off develop branch Hotfix/ - Bugfixes, based off master branch
- 38. eg. feature/jsconf > git flow feature start jsconf
- 39. Git Flow - Quick Recap Master - Official Release History Release - Combined features develop - Integration Branch feature/* - Development of Features based off develop branch Hotfix/ - Bugfixes, based off master branch
- 40. feature/jsconf -> develop > git flow feature finish jsconf
- 41. Git Flow - Quick Recap Master - Official Release History release - Combined features develop - Integration Branch feature/* - Development of Features based off develop branch Hotfix/ - Bugfixes, based off master branch
- 42. Git Flow - Quick Recap master - Official Release History release - Combined features develop - Integration Branch feature/* - Development of Features based off develop branch Hotfix/ - Bugfixes, based off master branch
- 43. Git Flow - Quick Recap master - Official Release History release - Combined features develop - Integration Branch feature/* - Development of Features based off develop branch Hotfix/ - Bugfixes, based off master branch
- 44. Code review Pull requests - feature -> develop - develop -> release - develop or release -> master
- 45. Oath - Thou shalt Only commit in feature branch Commit & push often Merge develop into feature branch everyday Only merge feature into develop, never master Only merge pull requests into master
- 47. Just having branches obviously not enough.
- 48. Environments
- 49. Local
- 50. Staging develop or release Local
- 51. Production master Staging develop or release Local
- 52. Production master Staging develop or release Development develop or feature/* Local
- 53. Development *.alpha.redmart.com develop to alpha.redmart.com feature/jsconf to jsconf.alpha.redmart.com
- 54. Deployment 1. Code 2. Push to git 3. Relax
- 55. Travis - Picks up branch (hence environment) - Runs tests - Create artifacts - Transfer artifacts to servers (based on environment) - Start application @ksaitor
- 56. Developer S3 (Artifacts) 2. Upload 1. Create Artifacts Push Build Fail Pass Slack SSH into Server `sh start.sh` 3. Get Server 4. Transfer Artifacts 5. Start App
- 57. Deploy with Git! Don’t mess with the developer workflow
- 58. Communication - New feature - new channel on slack #jsconf - builds go to slack - feature/jsconf get deployed automatically - eg. jsconf.alpha.redmart.com
- 60. Less Meetings ☑
- 61. INVEST IN DEVELOP LIGHTNING BRANCHES ARE IN INVESTMENT IN DEVELOPMENT ENV
- 62. How do we actually deploy them? Development develop or feature/*
- 63. Nginx # Feature branches server { listen 80; server_name *.alpha.redmart.com; # serve develop as default feature set $feature "develop"; ...
- 64. # change feature based on host if ($host ~* ^([^.]+).alpha.redmart.com$){ set $feature $1; } # All environments are hosted from a subdirectory root /path/to/features/$feature; }
- 65. Transfer & unzip artifacts of ‘feature/abc’ to ‘/path/to/features/abc’
- 66. It’s that simple? Yes.
- 67. It’s that simple? Yes.
- 68. Actually there’s more. Chef - Ruby based But I value my life.
- 69. Thank you LAH.
- 72. Extra
- 73. Applications - Must be environmentally conscious - Must know start themselves (Just makes it easier) - ci/start.sh
- 74. Developer S3 (Artifacts) 2. Upload 1. Create Artifacts Push Build Fail Pass Slack SSH into Server Chef Server Download `sudo chef-client` 3. Get nodes 4. SSH into Node & run Chef
Notas do Editor
- Hi Everyone! How’re we all doing? Mic test Where’s my applause crew? Sarmad? Cool HDMI, 720i, PAL (50hz)
- Hi! I’m Ritesh That’s me with the white arrow I do Frontend & Devops at RedMart We’re Singapore’s leading online grocer We’re building the next generation Ecommerce platform ERP Warehouse Transport Logistics Even a Robotic Trolley More than just the Website & API & We’re a startup
- Today I want to talk about how we develop features at RedMart We have a workflow that gets code to production fast
- We do this in a “No talk all action” approach I realise now this is a bad slide to have on a talk OK this is a bad slide, but what I mean is
- We encourage lesser meetings & more productivity I want to share how we do that. Hopefully with this talk, you can apply some of our workflow to help your team But if not, then if anything else
- You’ll get to hear about a real world development workflow of a scaling startup
- Raise of hands, How many of you guys have seen this site? I think it’s pretty cool don’t you think The CSS Animations - Wah damn power Lah I totally dig it.
- Let’s see if we can replicate it * GIT FLOW!! * Open up sublime * iTerm * grunt dev * remember to zoom
- Cool! So that’s done. I think it looks pretty sweet.
- So what just happened? I spent more time figuring out the projector & display stuff We deployed a feature into production in matter of minutes!!
- Yes it was Staged..
- Yes it wasn’t really a feature.. Just some CSS stuff
- But id’ say.. It was still pretty COOL.
- Where’s my applause team. Thank you.
- But in case you’re not convinced.. Let me tell you a bit of a story About why it’s specifically cool about RedMart
- & It’s about Product Market fit. I know you’re thinking.. what’s this douche talking about product market fit at JS Conf But...
- Bear with me. Many of us are working at Startups & I’m really fascinated how the business & company dynamics Especially how it impacts developers Because…
- Companies Scale Bro If you’re lucky & people start using your product & at RedMart count ourselves fortunate that we are You’re going to go from 10
- 100
- 1000
- 10000 Users/ Orders/ Messages Or whatever your measure of scale is As a result, You’re going to raise money
- & More awesome people are going to join your team
- To sustain & grow the company You’re going to be developing more features
- In fact you’ll be working on lots of features worked on by multiple devs at the same time & that’s a recipe
- For a lot of merge hells Dependencies issues Versioning & it’s multiplied with more people We need to tackle that
- But not only are there Developer issues We also have a lot more stakeholders This is especially the case for RedMart Due to multiple systems ERP Warehouse Transport Logistics More than just the Website & API And all these systems have stakeholders who we need to communicate to But even our systems are not the same The issue of communicating changes effectively & efficiently still applies to everyone Because.. as the team scales, you realize
- Huddling behind developers doesn’t scale How many of us have experienced that. People crowding behind you as you code, to get some update It’s so annoying! Worst still, change this Hex code to that, Not productive!
- On the other hand Bringing your laptop over every now & then Also doesn’t scale either We can utilize our time more effectively But then, this is super important We need to figure out an efficient way to get stuff out & comunicated Otherwise..
- We spend more time in meetings & less time writing code. Which is really depressing In fact it’s so depressing, we’ve actually come up with a theory.
- I’m sure you guys know about Einstein Mass Energy Equation
- We have another Theory Don’t have quite a name for it yet. Let’s just call it Thor Theory. I don’t know Environment that developers love, a productive environment Directly proportional to the code they write per day Inversely proportional to the meetings they attend per day Our goal is to optimize that
- So just a quick recap Companies scale Usually results in more meetings & More branch mess We need to fight that Empower developers to work on as many features at once So they can write more code & not have to spend too much time communicating So we can reduce meetings
- So how do we do that. How do we empower multi feature development The answer starts with Git Flow
- Most of you might know what Git flow is, bear with me again
- For the rest, here’s a quick recap Git flow is a branching model It’s a convention everybody in the team follows Ensures a sane branching state
- For our purposes The fundamental block are feature branches feature branches are where you write all your code It’s based off the develop branch
- For eg. What we did just now git flow feature start jsconf creates a branch feature/jsconf based on develop checks out that branch
- Develop branch is the integration branch It’s where you merge feature branches go once they’re finished
- So just now when we did git flow feature finish jsconf checkout develop merge feature/jsconf into develop delete feature/jsconf branch
- Release branches - is when we want to combine a set of features Especially useful when you want to stage completed features to deploy later Worked on feature a, b & c. Done & integrated in develop branch Now we to start feature d & e At that point it’s good to get develop merged into release & then not touch it until it’s deployed
- & as you can probably guess at this point master branch is official release history Anything that’s in master branch is production
- One last thing is hotfix It’s similar to feature branches, but instead of develop It’s based of master branch instead
- So git flow really helps to maintain sanity of branches You’ll also notice that 3 branches are kind of gate keepes develop release master so that makes it a common sense decision in terms of code review Any time a feature goes into develop, release or master we do a code review But Feature branches are cheap. Do whatever you want with them.
- So git flow helps But Oaths also helps. We specifically have these: commit in feature branch commit & push often In fact, every logical improvement to the code, should be committed & pushed merge develop into feature everyday merge feature into develop, never master merge only pull requests into master
- So as long as we follow git flow & stick to our oauth We’re really able to work on as many features as we like
- Just having branches is obviously not enough We still have to bring our laptops everywhere We need to deploy them & to to that, let’s talk about
- Environments Of which we have 4 & again we’ll see how git flow is the starting point
- The first one is Local. Local is straightforward. The developers laptop
- Then we jump to the 3rd one Staging I’ll come back to the 2nd Staging is equivalent to the develop branch or the release branch The reason for both: most of the times we don’t have release branch, If we do, it’s release branch otherwise develop
- & Obviously we have production Which runs everything in the master branch You’d think that’s the most important environment, but to us but actually..
- To us, the development environment is the most crucial That’s where all our features are deployed at every single push
- So when we deploy the develop branch, it goes to alpha.redmart.com When we deploy the feature jsconf, it goes to jsconf.alpha.redmart.com
- & the command to deploy The ever so loved ‘git push’ So literally all our developers do is git push Depending on what branch you push, it get’s deployed by CI process automatically
- We use Travis, but you could easily use something else. Basically, once you do a push travis picks up the branch & hence the environment & servers It runs the tests It creates the artifacts compresses, minifies, & zips it up Transfers the artifacts to the correct server & starts the application & we use Grunt here compressing minifying zipping transferring the artifacts
- That allows us to deploy with git commands Doesn’t mess the developer workflow Communication is also integrated into the developer worflow
- Everytime we have a new feature There’s a new channel on slack All the builds in the feature branches & pushed to slack Every commit is automatically deployed Just like in the case with jsconf feature earlier So we no longer have to bring our laptops over to show anything
- Every incremental change is communicated & we communicate in the best way we know how Which is code I don’t mean showing the code obviously, but working code that people can interact with.
- As a result of that We really do have way less meetings Play more foosball Turns out, everyone hates them. That was new to me I thought only developers did. :(
- So back to my Lightning slide cuz i love it so much What really is lightning branches? It’s actually nothing but an considered investment in the development environment Every logical improvement/ commit is important Not just the final deployment to production Lightning branches really inculcate the habit of pushing small incremental changes fast & getting feedback Which is really awesome.
- Now if you’ve been sleeping all along These last few slides are the crux of it How do you actually setup lightning branches?
- & the answer is really simple. Nginx It’s really good at routing & your SPA is really good at Being light weight & running just about anywhere So all you need to is this nginx server block Set a whitelist server name Set a default feature. We use develop
- Change the feature based on the host Set the root a specified location
- Then it’s just a simple matter of Transferring your build artifacts into the correct path on the server It just works!
- What. really? It’s that simple?
- Urmm… Yes.
- Ok, I mean actually there’s more. But it’s to do with Chef (which is ruby based) & I value my life. talking about that here.
- Blindfold you & drop you, you should know where you are