Deploying Marvin (the new Slackbot)
• Mark Eschbach
An application is all vaporware until it gets to a deployment environment. The best time to start deploying is at the start of a project. The second best time is now. Actually I generally feel the best time for deployment is right after you’ve got some value out of the application. I’ve tried the deploy first thing, but I generally get it threaded through then say “now what?”. Probably a sign I need to simplify my deployment process.
I’ve got two deployment paths for this particular target. The older host based deployment which tends to be a pain because I have to manage everything on the host. The other is Docker which is a pain for distributed discovery and generally feels more disk resource intensive and less permanent. For this track I’ll use Docker. My goal is to build the following pipeline:
- Integration
- Install any dependencies
- Unit and subgraph integration tests
- Install any dependencies
- Deployment
- Build container
- Spin up new container
- Retire old container
- Build container
I’ve got ten mintues before I move onto being a social human for today. Let us see how far I can get. Jenkins always would like to be upgraded; for another time I shall wait.
Integration
I always struggle to on the categorization of new jobs always. I’m just going to throw them in the general category. Eventaully I would like to better understand the pipeline job.
Generally it helps to have a repository to have Jenkins build things :-). I eventually need to see if I can break apart the Gitolite file into smaller files. Right, helps if I allow Jenkins to access the project.
Given my work at Rhumbix I’ve settled on versioning the CI scripts under a .ci
directory. This allows me to know what changed which feels a bit less crazy. Now with the job configured I need to set my .gitignore
and bring the project under Git.
Alrighty, I’m out of time. I’ve got the project setup in CI and failing when attempting to call npm
. Easy enough to fix later.