2 ms·

As a fellow "senior" programmer, I can barely imagine a non-side project that is small enough for me not to demand it running on CI.

eropple 9y ago
Agreed. My home server has a Concourse instance on it because setting it to run tests on projects takes, like...five minutes of editing a template. But, then, horror of horrors, it makes it incumbent upon me to write tests, and clearly that's just horrible. ;)
Silhouette 9y ago
As another "senior", I think these things almost always depend on context. Some of the shiny new tools and techniques really do move the field in a significant way. Most of them don't. The ones that do might advance one area but might not be particularly relevant or helpful in other areas. For example, personally I find it easy to imagine projects that don't have much need for CI tools, particularly not the formal ones that have "CI" in their name. Maybe a project is small enough that the only developer(s) involved are constantly making builds for test purposes and rebasing is standard practice when pushing to shared branches. Maybe a very large project has a complicated and carefully controlled branch/merge plan for their repository, and merges at key points are systematically checked following a whole review process. Either way, the extra effort to run a dedicated CI tool might not provide much benefit. Of course, in other cases, you'll be in a sweet spot for this kind of tool. Having something to automatically warn you if a key branch stops building could save a significant amount of time and trouble. The point is that it depends on your situation. Automating something means finding, learning and deploying software and infrastructure to do that job for your particular project. That's time and resources you aren't spending on something else, and these things are always trade-offs.

2 ms·

As a fellow "senior" programmer, I can barely imagine a non-side project that is small enough for me not to demand it running on CI.

by kristiandupont 9y ago

eropple 9y ago
Agreed. My home server has a Concourse instance on it because setting it to run tests on projects takes, like...five minutes of editing a template. But, then, horror of horrors, it makes it incumbent upon me to write tests, and clearly that's just horrible. ;)
Silhouette 9y ago
As another "senior", I think these things almost always depend on context. Some of the shiny new tools and techniques really do move the field in a significant way. Most of them don't. The ones that do might advance one area but might not be particularly relevant or helpful in other areas. For example, personally I find it easy to imagine projects that don't have much need for CI tools, particularly not the formal ones that have "CI" in their name. Maybe a project is small enough that the only developer(s) involved are constantly making builds for test purposes and rebasing is standard practice when pushing to shared branches. Maybe a very large project has a complicated and carefully controlled branch/merge plan for their repository, and merges at key points are systematically checked following a whole review process. Either way, the extra effort to run a dedicated CI tool might not provide much benefit. Of course, in other cases, you'll be in a sweet spot for this kind of tool. Having something to automatically warn you if a key branch stops building could save a significant amount of time and trouble. The point is that it depends on your situation. Automating something means finding, learning and deploying software and infrastructure to do that job for your particular project. That's time and resources you aren't spending on something else, and these things are always trade-offs.