Jenkins is quite popular. Anybody may download and use it. Just because. With an MIT licence.
Well, there are a lot of concepts for creating a CI environment.
The first one: every department has its own Jenkins.
The question is: who should monitor this? Should every team dedicate their own people? Should there be people in each team who are competent and the dedicated Jenkins techs are not needed? When something is not working, its effect is contained within a single field.
The second one: the company has a large Jenkins, and it serves all the teams.
Just like when the company has a product and all the other services serve it (microservice). Eventually, all of them exist for a single purpose and so are they interconnected. If an error occurs in any of the build processes, then the defective build should not get out. It is useful in integration tests when everything is at the same place. Projects to be built, integration tests and all the configurations concerning Jenkins are at a single location.
Of course, if the CI system needs to process quite some binaries, creation of a master-slave structure becomes necessary. The master distributes the tasks while the slave machines do them. Or the good old twiddling may come.
But when such a CI system is unresponsive, and when accessing the server, the admin can see that the CPU is running at 100%, well, then one needs to be smart. Someone may be running a programme which zips the entire driver (folder structure) into a single compressed file. This person might have looked around on the server and seen that it is full of interesting source codes. He makes reserves, downloads, and then analyses the files under calmer circumstances.
This might happen to anyone. This is why it is worth monitoring the CI, in case it became unresponsive. Especially that one which stores everything.
Developing with agile methods must be pretty much mandatory nowadays.
- Sending modifications to users as soon as possible.
- Ensuring that the developers can deal with development itself.
- Fastening the process by automatising deploy & release.
We also have lean tickets here. The point is that one must automatise whatever can be and is worth doing it. Everything that can release human resources, because human workforce is the costliest. In addition, one can have days when he/she oversees something; should he/she either have a hangover, be still drunk or just simply tired.
This is why it is good if there is a CI in the house. It runs unit tests, integration tests, and the functional tests. Provided there are some, but why should not there be some? A worthwhile startup may not afford not having any tests. One tough situation may make the users leave you. What would happen if there were payment-related issues? The user is there, wanting the yearly fee to be deducted from his/her card. And then nothing. But he/she would want it.
Tests can, however, prevent this. Selenium is quite good for automatic UI testing.
There is Continuous Delivery and Continuous Deployment, right?
Continuous Delivery is a series of practical steps designed to allow the code to get into the production environment quickly and safely through a production-like (stage) environment where one can make sure that all the apps and services are functional. We automatically run all sorts of tests that have merciless red lights when something is not functioning as expected.
Now then, if everything has gone to the stage environment previously, then it is quite probable that they can go live and there won’t be any issues.
Continuous Deployment is one step more than Delivery. The difference is that whatever passes the tests will go live without waiting for manual approval.
The teams that lay down the foundations of systems are usually made up of a few. So one must try to exploit one’s resources as best as one can. Most of the cases are about creating a CI build system through aggressive automation, and the project is then given loads of automatic tests. The CI then runs these tests and if everything looks OK, then the users can get their next iteration. A nicer, newer, better, and smarter version.