It was pretty much and eye opener, because, from what I heard, most of the problems that you would expect in that kind of scenario, where not happening! They release on time, and every two weeks. They do not loose changes, or have source conflicts adding new functionalities. Even when more than one developer is working on it. How did he manage to do that? Continuous Integration, he said. Although not the one you would normally expect to find.
It got me thinking. I asked myself, and now I ask you, this question: What is your definition of Continuous Integration?
If the answer was along the lines of "some software or script that builds your code when you check it into the source control system", I am afraid, you re missing the point. Continuous Integration or CI for short is not a particular kind software. Is not even a particular kind of tools or scripts. Its not about how you do it, but what you do. Its a practice. It is a process. It is, why not: a state of mind.
Yes, in my opinion you could say archiving "Nirvana" is not that different from getting your self and your team to interiorize, accept and incorporate continuous integration at an atomic level. No. I do not think I am over mystifying it. It is the equivalent of finding enlightenment and I will come back to this later.
But, the reason I am asking this question is not to explain, what it is or what he is doing. That has already been done several times and by people with more experience than I have. If you want to know go read the articles. Instead, I want to persuade you to give it a try if you have not. Maybe use it in your next pet project, or at work. I am hoping this post will give you the tools to make the sale to your team, or boss. Also, to help you optimize for developer happiness.
On the other hand, if you are already doing CI, hopefully this message will resonate with you at a personal level, and you will gain a greater understanding.
But, why would I want to use continuous integration in the first place? My process is dandy as it is right now, for me, and adding another layer of complexity and tools to it, doesn't seem to have a point.
Or does it?
What problems does Continuous Integration solve and How?
A co-worker and friend of mine brought to my attention this meme some time ago. I am pretty sure you have seen this situation before.
It is in Spanish, but the translation sort of would be:
John: None of the web validations work.
Girl: Well, it works for me locally!
Yeah... it is the unreasonable but yet frequent "It works on my machine" argument. Just because it works on your computer, does not mean it will work on the deployment environment, or the client's computer.
The problem here is that, usually, the developer's computer has certain particularities that allow the feature to function on his machine, but he forgets about them or does not know that they exist.
For instance, this could be changes done to his development database schema or data. For which he should have created migration scripts. New configuration files he added. Maybe, some sort of dependencies he needs but since he already had them beforehand, does not realize he should add them to the source control or packages manager. Maybe he was just careless and forgot to add that new source file to the version control.
All this means: "breaking" whatever is on the source control. Whatever is there, it is no longer deploy-able or demo-able, and if someone does a clean check out of the code, it simply, will not work. In some cases, it may take weeks or months before someone notices and tries to solve the problem. By then, it has probably grown out of proportion.
But the problem does not just end there.
When another co-worker tries to conciliate his changes with what is on the source control, it breaks his local copy of the code too! So he is going to go look and try to repair the mistake, and there you have it. More wasted time, delays, overlapping work effort.
Well.. guess what? If you are no alien to this kind of situations, you could benefit from CI.
Continuous Integration brings to the table isolation from each of the developer's environments by allowing a build to take place under a controlled environment. That is, an environment where the dependencies and configurations are known and theoretically, although not always possible, resemble the final production environment particularities.
This simple change in your software development process, allows you to know which dependencies you have and what you really need to do in order to build and deploy (in case you also stage your changes). So it reduces deployment risks and time, since you do it ever time you integrate (commit to the repository). If you wanted, you could give your testers or clients a deployment ready version on each commit and get some feedback.
As a by product of this you also make adding new developers to the project a lot easier. The time they spent configuring and tweaking what they get from the source control, to make it work, is ideally none. This is time saved that they can spend in really getting to know the ins and outs of the project, instead of "expending" it on putting up the environment.
Also, by executing and assessing this build on every commit, you can know right then and there, that something fishy is going on, because it will not build, run, or pass some tests. Did I forget that library? Did I forget to check in the new configurations, etc.
Not just that. If you are doing some kind of tests *grin*you are, right?*grin*, you can add them as part of the build process, so you can find out if you broke some of the functionality too. Also, if by any reason you have some code quality standard, you can also add that there!
Are you using some sort of continuous integration system and you do not have tests? That is like, ordering a diet coke, to wash down a big and greasy hamburger....
By the way, if you are not doing tests... Weigh the benefits and costs.... Well. Not really no. Just start doing them.... ;)
The truth is, tests that you can add to your build process increase your, and your team's confidence in the code state, at all levels. You make sure the code compiles. It passes all the tests for the new and old functionality (functionality is also correct) and it adheres to the conventions and quality checks that your company or your team has in place (structure, style, common errors, and metrics).
Just, pay particular attention at the fact that I am not talking about, unit tests, or integration tests, or anything in particular. Any kind of test will do, as long as you make it part of the build process. That includes, monkeys smashing their hands into the keyboard and mouse (or Q.A.). Although it does not have to be that way.You could have automated tests, but that is another story I am going to be talking about in later posts.
Last but not least, it helps you get rid of that code integration hell. Yes, that guy who is working on feature for two weeks and has never, ever, during that time, merged what is on the trunk into his branch or local copy. Yeah, the one that saves all the fun for the end. This is where the "continuous" comes into mind, and mostly why this post came to be.
When I mentioned adopting CI was a lot like reaching "Nirvana" this is what I was referring to. Tools are just that. A good hammer can be used to take a nail out, or put it in, although consequentially it can also be used to crack someone's skull open. It is all in the way we use them. This is where continuous comes in, because in a great deal it is referring to the human factor. To the when. It says: you need to integrate, and do it all the time!!! However, it is along with testing, the part that we neglect the most. We tend to forget about it, because it is difficult to tackle. Because it involves refactoring the wetware. It involves developers caring about this kinds of things, not just seeing the source repository as yet another kind of network folder.
You and your team need to commit, and therefore integrate, your changes, all the time. This prevents duplicated effort and provides an opportunity to have smaller and easier to handle conflicts as opposed to having one huge unsalvageable one! It saves you time, it saves you "bling bling", and it sure adds years to your lifespan. It also gives you an opportunity to resolve the conflicts as they happen, when the people who created them are there to solve them.
Just imagine one of your co-workers is working on a new feature or a bug. He has everything on his local computer and he says it is "finished". It works! But, he is leaving on vacations and he will not be here for your next release. You are in charge of putting everything together.
So now, you do what every sane person would do and try to commit the changes to the repository, only to find everything has conflicts. It turns out creating this new feature or solving this bug needed a lot of rework. What the hell are you going to do now?
You are going to "try" to solve the problem, and you may just do that, but you are definitively not the right man for the job. That, is what I mean. By the way, this is more common than you could think.
I hope I explained my point of view and maybe, sparkled in you that curiosity and ingenuity that takes to make things better for yourself and everyone else. Maybe now you can make an informed decision or pay better attention to the human factor in your CI system. Anyways I hope it was useful.
In upcoming posts I will be talking about how you can set up your own continuous integration server, for Java or .NET. Keep tuned, and happy coding!
No comments:
Post a Comment