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.
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
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
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
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
58. Communication
- New feature
- new channel on slack #jsconf
- builds go to slack
- feature/jsconf get deployed automatically
- eg. jsconf.alpha.redmart.com
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’
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 del 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