I've recently discovered nice continuous integration and continuous deployment service – codeship.io. It's not just another hosted Jenkins and it has some very interesting features (like integration with major code hosting services and development tools). But I won't probably use it except maybe for some pet projects of mine with no active development. Here are my reasons why:
- Free plan is no good for even one project. 50 builds per month is not enough for anything: any project in active development usually needs several daily builds, even if not counting merges and feature branches. Commit early, commit often (and with CI it also means test often) is the usual approach of our days.
- Cheapest paid plan costs $50 per month. Yes, it has unlimited almost everything, but fifty bucks is small, but significant amount of money and small business (or non-profit project) can usually utilize them better.
- Setting up Jenkins, on the other hand, would cost you about $5/mo for hosting and couple of hours of sysadmin's work.
They also have larger plans and all paid plans are structured by number of concurrent builds, the only limited thing in the system. And since I was asked in twitter how would I structured pricing of such project, here follows my ideas about it:
- "Pay as you go" pricing is good. AWS is very popular partially because of that. Plans with some amount of batteries included are good too, but it should not be mandatory. So if you just starting development and don't need much of testing or just ended active development and build/deploy only occasionally, you can pay a few bucks, but if you're active user, you pay more.
- Free plans are not required if service is cheap. It's usually better to have ten customers paying $1 than to have one customer paying $10 and twenty free riders. I'm not saying that some free plans or time-limited free trials don't help to review and test, they do help, but good cheap service is better than bad free one.
- Most costly resource for continuous integration service (apart from development cost) must be the build time (time of using build instances, if we're talking cloud, or or cpu time if we use some other virtual machines, like, on our own hardware). Maybe also storage, not quite sure. So it would be better to charge less for less time-consuming projects and more for more time-consuming. Number of concurrent builds, number of total builds are not that important: some projects may be compiled for hours, some are built and tested in a few seconds.
- Maybe optional delayed builds could be a good way for saving for some users. Like AWS has "spot instances" to utilize unused resources. Delayed builds could either use spot instances or use reserved instances when no one else uses them. Because no everyone needs instant builds, I can imagine someone want, like, 30% discount for builds delayed up to one hour, for example.
- No build time used – no money charged. Except maybe for something little for storage and other costs.
It's not like I'm going to start competition tomorrow, so my observations are mostly from user's viewpoint, but if I were starting it, I'd do it like I said and would probably take a significant market share (given the competitive technical qualities).
P.S. Also, small technical side note, I don't like their lack of periodic builds and ability to use custom git repositories (not on github or bitbucket) – some people just don't use github for various reasons (they claim to fix this soon though) and periodic builds might sometimes be helpful for "nightly" builds (there are projects so big that it's not worth it to build them more often anyway).
P.S. Also, small technical side note, I don't like their lack of periodic builds and ability to use custom git repositories (not on github or bitbucket) – some people just don't use github for various reasons (they claim to fix this soon though) and periodic builds might sometimes be helpful for "nightly" builds (there are projects so big that it's not worth it to build them more often anyway).