Is Code Green In Jenkins Enough?
An INFJ personality wielding brevity in speech and writing.
If you’re not familiar with Jenkins – it is software that simplifies the building of a continuous integration (CI) server with a web interface. Jenkins checks out code from a source code repository like GitHub, then builds that code, test it, and delivers different kinds of reports – passing/failing, code coverage – about it. Jenkins doesn’t eliminate the need to create scripts for individual steps but it offers a faster and more robust way to integrate the entire pipeline of build, test, and deployment tools.
Before Jenkins, developers had to go through the awful experience of nightly builds. The only other option they had was to build and test carefully on a local machine before committing the code, which was done in isolation without anyone else’s commits. Obviously then there was no assurance the build would survive one’s commit. Enter Jenkins – a direct response to this limitation.
It’s really easy to get up and running with Jenkins. Here’s a short list of basics you need to get started:
- Implement version control of your choice, like GitHub
- Write tests for the key parts of your code base and treat tests as production code.
- Get a suitable CI (you got that with Jenkins) that will allow you to run tests on every check in to the repository, and will also deploy your builds.
- Think of the different components of your software as building blocks that must fit and work well together to become something meaningful. It’s not enough for a specific piece of code to function well on its own. It must integrate well with everything else through continuous integration.
Jenkins gives you quick feedback (relatively speaking) about broken builds, which is great but only if those bugs are detected and dealt with immediately. Usually, such bugs get swept under the carpet because your focus is on meeting deployment deadlines. The whole team needs to be committed to high quality and understand the value of addressing issues immediately and keep technical doubt to a minimum.
Automated software testing
Now here’s the proverbial fly in the ointment. The thing with bugs in software is that they hide other bugs that hide other bugs and so on. As the bugs pile up it gets harder to test and find them, resulting in nasty surprises. But if various kinds of useful automated tests are run in your continuous integration pipeline, you’ll be able to know what to fix as soon as a test fails. Not all of the testing can be automated and it takes time to automate what can be automated, but doing so helps you develop software in a sustainable way and keep the technical debt at a minimum.
Now when we speak of CI and continuous delivery, it is not enough simply to automate tests and feed them into Jenkins. What you also need to do is build the right kinds of tests that are user-friendly and help meet customer expectations it – essentially, design and automate the right kinds of tests. Writing tests that examine code on different levels is often skipped, while incomplete tests are abandoned and never rewritten.
So what should you do? Spend a substantial amount of time in writing real, comprehensive and useful tests. The extra effort will pay off later and save time spent on debugging issues that could have been detected by tests. You could spend the debugging time on writing code for new features instead.
Think strategically to identify what kind of testing will get you the best results. Unit tests should be written to check your implementation of functions, integration tests to get different components to work together, while acceptance tests will validate important business requirements. Even when all your tests are ready, perform exploratory testing to discover issues that even Jenkins (automation) could miss. Building high-quality software is very complex and getting it right is difficult but imperative. Using the right tools helps programmers on track and supports the development process.
Another thing I would like to point out is that the easier it is to test something, the easier it gets to determine its quality. So if your code is written in a manner that doesn’t allow writing tests for it, it will be very hard to test for and remove bugs.
One Comment
Leave A Comment
Related Posts
This is really an excellent article and more essential too!!