7 ms·
Every time I read one of these (Github, Etsy, ...), I feel a bit guilty that our tiny startup doesn't do continuous integration/deployment. I mean, we git push
by socratic 15y ago
Every time I read one of these (Github, Etsy, ...), I feel a bit guilty that our tiny startup doesn't do continuous integration/deployment. I mean, we git push to Heroku to deploy (maybe once a week), but there is no automated push once the tests pass. It seems like this is a big psychological leap (deploy every week vs deploy every hour).
When does setting up something like Jenkins CI become worth it? When you have 2 people? 10 people? 100 people?
Is there tons of custom code to set it all up with Github or whatever deployment scripts exist? What CI systems are dominant? (I'm mostly curious about Ruby-centric ones, but don't really want to bias responses.)
- LiveTheDream 15y agoIt's worth setting up Jenkins even with 1 person if it's a serious project. It is ridiculously easy to set up, and it's a "set and forget" procedure. This is orthogonal to continuous deployment, by the way.
- bostonvaulter2 15y agoWhile I agree that it is orthogonal I would highly recommend setting up continuous integration if you do continuous deployment.
- LiveTheDream 15y agoAgreed; I can't imagine CD without CI. However, CI without CD is pretty normal.
- X-Istence 15y agoI recently set up Jenkins for a team of 6 with backend/frontend and it was easy and fast to set up. It is nice to automatically have reports added to JIRA when stuff builds correctly or fails, and XMPP notifications allow developers to be notified if something they pushed has broken the build.
- bostonvaulter2 15y agoWhat do you use the XMPP over? google chat? Or other XMPP chat programs?
- X-Istence 15y agoWe have a local XMPP server set up on the network, and we all use various different clients, I personally use Adium, we have some developers using Empathy on Linux, and others using Pidgin on Windows. Jenkins has an account on said XMPP server (our AD logins actually) and is thus able to send messages to the developers that are signed on. We also have a "conference room" set up on XMPP that every developer is logged in to most of the time, and Jenkins is available there to run commands, so you can for instance say !build android-client and it will start building the android client, test it in the emulator and report results to the chat room.
- sifi 15y agoIf you don't mind me asking what XMPP server are you using? I'm guessing that this is a pretty powerful computer to run the emulator on?
- X-Istence 15y agoI don't know what XMPP server we are using. I was not the one that set that up. I only have access to all of the FreeBSD/Linux machines in the company, someone else gets the pleasure (or should I say displeasure) of managing all of the Windows server infrastructure (AD, File servers, stuff like that), including where our XMPP service is being run because it requires AD access. Upsides and downsides to being the only developer in the company that knows Unix... We have a gitorious server that also has a jenkins account (jenkins connects over SSH). It is running within a VMWare Virtual Machine with access to 4 cores running at 2.4 Ghz, and 14 GB's of ram. Whenever jenkins notices a change in git (using polling, every 5 minutes, set up for now, eventually I'll get around to doing push notifications of some sort ...) it pulls down the latest source code, and starts up the Google Android emulator (basically qemu for the ARM platform with the devices as an Android phone would have them), once that is started up it compiles the source code (java) and using adb installs it on the phone, runs the test suite, and reports any errors back, Jenkins then shuts down the emulator. It isn't extremely fast, starting up the emulator takes about 50 seconds or so, and I am trying to get a faster server to use as a jenkins build slave, but for now it works wonderfully. Everything I mentioned is completely managed by jenkins.
- rtomayko 15y agoAssuming your main product is on the web, you really only need a few things to do this right: - Automated tests that run on push to any branch. - Rolling deploys (no downtime) from any branch. - Exception reporting system (Exceptional, Hoptoad, homegrown, whatever). - Twitter search feed. Push to a topic branch, wait for the tests to come in green, deploy from topic branch, watch exception notification and twitter. If everything looks okay after 10 minutes, push to master. If exceptions or twitter blows up, redeploy master. You should be able to setup the whole system in about the same time as it takes to develop a majorish product feature.
- tim_iles 15y agoSorry, what do you mean by Twitter search feed?
- damncabbage 15y agoA search for the product's name or handle on Twitter to detect a surge of activity post-deploy. (Most surges are negative, eg. "Man, <YourService> is down AGAIN, this sucks.")
- cstejerean 15y agoI assume watch a feed on Twitter for a search about your company or product. If people on Twitter start complaining in mass about your latest push it's probably a good sign that you need to roll back.
- tim_iles 15y agoOk, this is what I also assumed - although I would never rely upon this as part of my continuous deployment process, I guess it does little harm to still monitor and be aware of such things...
- mncaudill 15y agoAt Flickr, I always have our system graphs in one tab and our help forum in another tab.
- kisielk 15y agoDon't wait. Jenkins is literally one of the easiest pieces of web service software you could possibly set up. All you need to do to try it is download a jar file and run java -jar jenkins.jar. That's it! I run it on my personal computer. I also set it up at our company, where I'd say the active user base is around 10 people. It's useful in both cases. Jenkins has plugins for everything, and soon you'll be able to develop plugins in Ruby, and without maven, so if you don't have what you need you'll be able to add it.
- madflo 15y agoI compete with myself on a daily basis to add some points on my coverage %. Having a tool like Jenkins to graph my progress helps a lot.
- mseebach 15y agoSo, as others have pointed out, what you're really asking for is continuous deployment for which CI is prerequisite. I think doing CD as early as possible in the project is very worthwhile: It forces you develop high confidence in your app from very early on. When committing your work means that users will be using your code in a few minutes time, you get in the habit of making sure that you have appropriate test coverage for the code you're committing. This also makes it more difficult to take shortcuts or "I'll add tests around this tomorrow". If you don't get in the habit of CD early on, you're risking developing bad habits such as manual testing or hard-to-automate release steps which makes it progressively harder to start doing CD.
- aespinoza 15y agoDon't feel bad about it. Always do what makes sense for your business. If you can handle doing it manual, do it. There will be a point where you are growing too much and too fast, and you loose too much time deploying, then look for implementing CI. A lot of people will tell you to use CI from the start. And our startup has been using CI since the beginning, but there was no apparent benefit in the start. It was only 1 full time developer, and a second part time. Right now we couldn't live without it, but this is because our applications has grown considerably, and the speed at what we are implementing our ideas is fast. Loosing time doing Deployment and running tests manually would be a great loss of time and of flow. CI is only worth it, if there is a benefit for your project.