73 lines
2.4 KiB
Markdown
73 lines
2.4 KiB
Markdown
# Central Tenets
|
|
|
|
* deploying should be as easy as pushing a button
|
|
* reverting should also be easy as pushing a button
|
|
* bad deployment processes impede development speed and innovation
|
|
* they create a negative feedback loop of anxiety and fewer pushes
|
|
* good deployment proesses foster development and innovation
|
|
* code isn't useful until it's being used
|
|
|
|
## Hypothetical
|
|
|
|
* you have a new feature or a bug fix that's in a rush
|
|
* deploy: what's the worst that could happen? Disaster.
|
|
|
|
## Do you have more than one way to
|
|
|
|
* deploy code across teams?
|
|
* deploy code amongst a team?
|
|
* deploy a single app?
|
|
|
|
* having a single process is best, especially in the latter two bullets
|
|
|
|
## Our old deployment setup
|
|
|
|
* Debian packaging -- process wasn't maintained, people started wanting a new way to deploy code
|
|
* SCP un-versioned tarballs -- miserable failure
|
|
* Chef installing packages -- worked for a little while, but Chef deployed every 30 mins whether you liked it or not
|
|
* pip installations -- today's talk
|
|
|
|
## Choose one deployment method and stick with it
|
|
|
|
### Python-based packaging
|
|
|
|
* Python & Setuptools to build packages
|
|
* PEP 440 versioned packages
|
|
* pip to install Python packages
|
|
* Jenkins for CI and package building
|
|
* Chef for initial deploy and service discovery
|
|
* Fabric for gluing the pieces together
|
|
|
|
### How does it work?
|
|
|
|
* Github used internally
|
|
* Jenkins job runs tests, builds a package, uploads it to an internal PyPI server
|
|
* Project-specific Jenkins job triggers generic deployment job
|
|
* Generic deployment job queries Chef server via Fabric
|
|
* SSH into each node and upgrade the Python package, pip install 'u
|
|
* job restarts service which loads new code: kill -HUP <pid>, test the new code
|
|
* control flow returns to the project-specific job
|
|
* notify monitoring that a deploy happened, include v. and timestamp (HipChat, New Relic)
|
|
* rinse and repeat for all nodes
|
|
|
|
## Key takeaways
|
|
|
|
* choose one deployment strategy and iterate on it -- team-wide or org-wide
|
|
* code can be deployed in parallel
|
|
* services should be bounced sequentially
|
|
* centralized deployment job makes for easy rollbacks
|
|
* other codebases can use similar deployment setup
|
|
|
|
## Shortcomings
|
|
|
|
* fixing old code deployemnt is very painful
|
|
* strongly coupled with Chef for service discovery- not great with edge cases
|
|
* Jenkins not the greatest continuous deployment server
|
|
* initial hacky usage of Fabric in early stages
|
|
|
|
# New vocabulary for me
|
|
|
|
* "internal PyPi repo"
|
|
|
|
|