How to improve you continuous integration
Wouldn’t be great having a large number of developers, even multiple teams working efficiently at the same time on related software systems and functionalities, and seeing them making changes without blocking or molesting each other while keeping the source code coherent and behaving as expected by the user.
In organizations of all sizes , without practicing continuous integration you might experience that
It's difficult to get software to the customers, due to a myriad of issues. It's difficult to make changes without affecting others -> How to make changes witout affecting others You are overburden with coordination my changes with others, -> How to coordinate code changes with outhers It's hard to keep updated with the latest changes on the source code. -> I constantly find my changes incompatible with others It's difficult to understand if the system is ready for the users.
If you experience this problems don't worry , by the end of this article you'll have set of simple steps on how to solve them.
How can you do it?
There are 3 key steps to successfully implementing continuous integration. • Commit changes to an agreed main line version of the code. • Build the software from that main line version. • Validate that the build software behaves as expected.
The fastest and more frequently you are able to perform this steps every time a change is made the better.
Let's dive into each of them.
Commit changes to an agreed main line version of the code.
In many ways Writing code is like writing a book. A book is being written at the same time by various people, the author, may be the coauthor and editors. Who has the final version of the book?. In the publishing industry as an author you might stop writing at a point and past it to an editor, from that point as an author you've done and you only let the This dilemma is what you find in many software organizations. And to solve it what you'll try to do is to put those changes into .
When your organization practices CI, developers integrate all their work towards a main single version of your code on regular bases. Levering the code base to show a single primary view. This is called in technical circles as committing code into main, or trunk. This is a proven approach to synchronise your changes with everyone else working in the same source code.
To be able to do this you need to instruct everyone modifying the code to integrate all their work towards a main single version of your code on regular bases. Levering the code base to show a single primary view. And as in the book authoring the more often you get everyone to have the latest view the fastest you can move on with confidence to publish the book.
Once you have everyone committing the code into main or trunk. It is time to works towards doing it frequently. Ideally multiple times a day. If this seem unarchivable or very difficult stablish a first baseline and work towards increasing the cadence, the same way you'll train to run a mile in less time. (reach out to me if this seems very difficult … as moving parts…)
Fun fact: "DevOps Research and Assessment (DORA) research (PDF) shows that teams perform better when developers merge their work into trunk at least daily." Once you have that main view version it is time to build it.
Build the software from that main line version.
So you have now a main view of the code, you might ask yourself , is this version coherent? And then only way to do it is to build it. Following the book publishing methafore, Are all the sentences following the correct grammar, do the paragraphs connect correctly, and the chapters.
In software there's more than that, but the idea is the same you need to create a bundle deliverable that can be run by a computer. (binary, executable)
I can't describe here all the ways you build software, but least to say that usually you run a set of programs, and scripts to make it happen. As long as you are able to create a quickly, consistently and without having to wait for someone or something to happen or be available you'll be alright.
Once you are able to build the executable bundle, It is time to make it faster and make sure validate that the built software behaves as expected.
Validate that the built software behaves as expected.
So you have now a main view of the code that has been build. How do I know if it does what it was designed to do? In our book metaphor. On the first chapter, the expectation is that the reader can visualise the characters, and in the second chapter that the reader can provide feedback on the characters.
In software development we might check that the screens or pages of your published website show certain information, or that when a form is filled it actually generates and saves an electronic record. You can perform this activity manually, however doing it manually might take you a while and if you have many people making changes you might find yourself struggling with errors, and if you can't stop it …
There are 2 important things here. The first one is that testing must give you confidence that what it has been produce is what you expect for the user, and the second is that to make this step worht you need to educate your team to consistently stops what they are doing to fix the problem immediately.
If you find hard to educate your team to stop when a problem areaise. …. Making changes and Commit code is a team effort. This is like running a car factory and finding that the engines are not starting once the car is finished. To stop a potential massive rework in every car, up to that point in the line, and wasting time and materials towards bad cars. It is better to realise that The most important thing to do is to stop and check where the problem came from and fix it. Usually we think of faults as originating from one person or faulty steps, but it is important to note that most often than other it is a set of compounts errors here and there, made by multiple people that produced the chain of the issue being detected.
If you are not confident, it means there's gaps on your test coverage and what makes you uncomfortable is what you have to test. So if you are not confident about what' you build you need more test.
Stablish test automation practices first, so that a suite of automated test run both before and after the changes are committed to the main line in order to validate that changes haven't introduce any incongruency, bug or errors in the code, that is changes that have side effects and produce errors or bugs in other parts of your system or software.
Introduce a new way of working so that If these automated tests fail, the team consistently stops what they are doing to fix the problem immediately. Commit code is a team effort.
Stablish test automation practices first, so that a suite of automated test run both before and after the changes are committed to the main line in order to validate that changes haven't introduce any incongruency, bug or errors in the code, that is changes that have side effects and produce errors or bugs in other parts of your system or software.
Challenges with poorly implemented continuous integration.
How to improve you continuous integration?
If something takes a long of time and energy, do it more often so that it becomes less paintful, as long as you adapt.
Create rapid feedback loops and ensure that developer work in small batches.
Continuous integration comes from Kent Beck and the Extreme Programming and defined as as defined , explain by martin fowler https://www.martinfowler.com/articles/continuousIntegration.html with colonaries
• ideally with the suit of automated tests
Make sure that provide feedback in a few minutes.
Look at your test and see if: Do tests give you confidence that the software works as expected? tests execution to get feedback should be in the a few minutes or less.
How to create a suite of automated test? Creating maintainable suites of automated unit tests is complex.
TDD->process + modularitiy
You might require p large features and other changes into smaller incremental steps that can be integrated frequently into trun
Benefits Reduce cost of changing and maintaining your software, while increase the efficiency and ouput per hour of your developers.
PDF research CI leads to higher deployment frequency, more stable systems, and higher quality software.
Problems: I don't have a system to share my code, -> How to share your code using source control, source repositorites? It's hard to automate the building process -> How to auomate the building process It's hard to automate the test -> How to auomate the building process It's difficult to get the test using My team is not fixing the broken builds right away