4

Background

Team/Project Size

Currently at our company, we have a team of 3 developers. We each have our own projects that we work on. So, we never have more than one person working on a software development project at the same time. Once in a while we may have a developer go and modify another developer's project (months or years down the road).

Project Management

We follow the waterfall methodology very closely, and it works well for us. We are given a set of software-design specifications that stay the same for 30 years (or longer). Once in a while there may have been a typo or mistake with the design specification and the requirements may change slightly, but this almost never happens.

Issue Tracking

We do get bugs in our software, but these are typically reported quickly by our small user-base (10 - 15 people) and fixed right on the spot. We then release a new version of the software with the integrated changes very quickly, and never have to do anything again for years.

Version Control

We have Git repositories on our company shared drive that we use to maintain the software versions and keep track of changes.

Question

I brought up the idea of using a continuous integration with something like Jenkins and was told it wouldn't be necessary. Given our environment, should we be using CI?

Additionally, I would like to know how it will affect me personally if I never learn CI.

Improve this question
4
  • Do you have unit tests? Commented Apr 11, 2016 at 11:36
  • @paj28 No, we do not. Yet. Commented Apr 11, 2016 at 11:36
  • 2
    Sounds like the wrong environment. CI is pretty limited without automated testing. Affect you personally? Not much, many places use CI, but not knowing it won't hurt you job prospects much. Commented Apr 11, 2016 at 11:45
  • 2
    @paj28 you've never forgotten to check a file in? Even without automated tests, a build server is worth it's weight in gold. Commented Apr 11, 2016 at 11:57

2 Answers 2

Reset to default
4

Go for it - Jenkins is an awesome choice for CI server, is easy to set up and work with. It doesn't take much server resource either.

What CI gives you is a computerised 'build person' who can take your code from a repository and build it without your assistance. If you quit or get hit by a bus, this means that your code will still be usable without whatever bits you might have on your computer that you forgot you had. If you can build it on the CI server, then its a good, reproducible build.

This is the main point to a CI server. Sure, it can do more than that, like run tests or make builds that several people have contributed to but these are secondary to the primary purpose of making sure that your build can be built by someone else. It also means that what is required for your build to work has to be known, ie if you install some tool and forget that its there, the build server will fail to build until you remember and install (and hopefully document) it on the server too. Your build server becomes a gold standard environment for building your products. If you hire a new guy, he'll be able to get up to speed just by copying the build server specs.

So: get a new server (or old PC lying around). Install Jenkins and all your build toolchains. Set up a Jenkins job for each of your products to checkout from master and build. Then look at the pretty web-based dashboard saying that each product has built successfully.

If you want to get fancy from that point, you can deploy to a staging area so your products are always consistently delivered to support, add static analysis, testing, and other coolness. Its just added quality and reassurance that everything is working properly. You won't look back.

Improve this answer
4

I think it's an excellent mechanism to use. You're going to be able to confirm that your own builds (if no-one else's) will work in an isolated, reproducible environment. It'll check if you forget to commit work in your SCM system, and that the builds and tests all work in a controlled environment, independent of your personal environment. If your tests take ages to run, it'll offload the work to another machine (assuming you have a separate CI environment) so that you can continue to work whilst those are running, and you'll have a history of your builds such that you can identify regressions and tie those to commits.

If your company really don't want to do this (and it seems very short-sighted), why not just set up your own personal CI system (on another box, or perhaps as a different user id on your development box). Even if others don't want to benefit from the above, you can.

Improve this answer
5
  • But I would have to set up a server just for me? Doesn't sound like it would work based on our environment would it? Commented Apr 11, 2016 at 11:32
  • 1
    Please don't mix up Automated Testing with Continuous Integration. You can have the former easily without the latter. Commented Apr 11, 2016 at 11:33
  • @ThalesPereira who's mixing up automated testing? Commented Apr 11, 2016 at 11:34
  • 1
    I'm not confusing CI with automated testing, but the CI gives you the automated testing in a proper independent environment such that you don't have to worry about it Commented Apr 11, 2016 at 11:34
  • @BrianAgnew All of the benefits you cite are given to you by another tools, not directly by CI. CI is about code being synced up often - if you don't have other people to sync it up with, you have Automated Testing and Automated Build - which, while used by CI, are not exclusive to it. Commented Apr 11, 2016 at 14:07

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.