BackgroundTeam/Project SizeCurrently 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 ManagementWe 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 TrackingWe 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 ControlWe have Git repositories on our company shared drive that we use to maintain the software versions and keep track of changes.QuestionI 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.
Is this the wrong environment for CI?
testing;project management;team;continuous integration;jenkins
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.