What is Continuous Integration?
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2019
- Learn more about Continuous Integration: ibm.co/2naimDE
Grow your skills and earn a badge with FREE browser-based Kubernetes labs: ibm.biz/kubernetes-browser-bas...
In this video you will learn what continuous integration is, the difference between the old way of infrequent integration vs new way of continuous integration, and the benefits of doing it, with IBM Cloud's Eric Minick.
Get started for free on IBM Cloud: ibm.biz/lite-cloud-account-signup
#devops #continuousintegration #ibmcloud - วิทยาศาสตร์และเทคโนโลยี
"If it hurts do it often and it won't hurt so much" 👌
This was great. People always talk about CI/CD together and I love how you separated these two. Definitely will look for more vids from you. Thank you!
This is the first time I got a clear explanation of what is CI, good job!
This entire mini-series is excellent!
Thank you so much. You took the time and made the effort to help yoir audience understand just what Continuous Integration is including its premise, that answers the why and the resulting benefits. Salute!!! Thank you for your charitable contributions.
This was an extremely helpful video. Thank you.
Very clear explanation of CI. It can be hard to find a clear definition of this that doesn't go into the various kinds of CI/CD pipelines that are possible, so thank you for this.
Glad it helped!
Best explanation that made it super simple to grasp for network engineer! Thank you
So happy to have been useful! Been banging around the CI space since 2005 and happy to teach!
An exceptional explanation of the topic, Thank you.
I used to always mix what does what, but your video easily clarified it for me, thank you so much!
We're happy this was useful to you, thanks for watching! 🙂
Love this video! Thank y'all so much for posting.
thank you very much, your lesson is very helpful for my work.!!!
Great Erick! Very helpful video to understand the basics.
Thanks, Daniel.
Great Explanation . that was really helpful !!
Great job on that video, Erick-you really knocked it out of the park!
Thanks for the appreciation! 👍
This IBM channel is so underrated when it comes to teaching.
Thanks so much for this tutorial.
Wow, this has been extremely helpful and illuminating. Thank you so much!
You're welcome, glad you found it useful! 🙂
Very very helpful. Thanks much mate 👍
Very good and simple explanation, thx :)
Thank you very much, great explanation
GREAT explanation!!
Brilliant overview of the concept of CI
Thanks Pankaj!
These videos are AMAZING!
Perfect explanation Thanks alot
Great explanation!!!
great explanation! thanks
Amazing summary of CI for a non developer to understand ;)
Amazing Explanation!
That was a great explanation! Thanks
Thank you!
I love how there's a video explaining CI as a single concept then another CD video. Usually you're always faced with CI/CD as a single "concept" and showing the clear border and what is what is extremely helpful to understand these 2 concepts better.
There's no link or mention of any CD video here
@@furrylovebear6844 th-cam.com/video/2TTU5BB-k9U/w-d-xo.html
@@furrylovebear6844 problaby this: 2TTU5BB-k9U, it showed up on the recommendations.
clear explanation! thanks
Super and easy... keep going posting such videos, really need guys with very clear on subjects.
Thanks for the great feedback, Kumail! 🙏
what a great explanation, ty
Thanks, very educative
*(Active recall)*
Core principle:
Continuous integration is oposed to:
Benefits of continuous integration:
----------------------------------------------------------
3:23 Core principle: "If it hurts, do it ofent and it won't hurt so much."
5:43 Continuous integration is oposed to the old way of infrequent integration.
5:53 Benefits of continuous integration:
1. Avoids merge hell.
2. Constantly gives us a testable build.
3. Keeps the developers productive.
Thanks for the help!
best explanation on the internet
Thank you and keep up the good work!
Eres lo mejor que me ha pasado :)
3:30 that... that just changed my life. Wise words. Wiser have never been spoken.
:)
good explain! thanks
Thank you Eric that was helpful
Glad you found it useful, thanks for watching, Haroun!
Very helpful video
wow nicely explained
Crazy good explanation
Thank you!
Amazing video.
👁️🐝M! Nice ) Thanks for the video.
Thanks!
So is my conclusion right:
Feature Branches are not used anymore unless its a Spike/Experiment or some standalone Feature?
Like i am wondering:
Of course i could create small tasks and small feature branches that are merged in a day or two but in that case why would i need a feature branch. I could just develop that on the mainbranch (dev) aswell.
Feature branches are still common and with GitFlow, they may be the norm. The lesson from CI though is that branching is hugely expensive and that expense grows faster than linearly with time. Short-lived feature branches are ok and can be seen as an extension of "the code on your laptop that hasn't been merged is a branch". Long-lived ones are toxic.
My solution has always been pull-push on EVERY commit. And I commit often; probably too often. Example: if I am working on a story/feature and I notice something trivial like a typo in a comment, I will stash or commit my feature-related changes up to that point, fix the typo, add and commit it in its own commit, and get back to feature-related changes. I would push and pull for each of these commits. Obviously, I wouldn't need to pull twice within like 2 minutes, but I would do it anyway, just because it would bug me otherwise. Honestly, just doing it inside the same branch as the feature bugs me, but I just bite the bullet there, because that is when coworkers start to get annoyed. But if I was working on a solo project, I definitely would. Rule #1 & Rule #2 for me: _A_ _place_ _for_ _everything_ _and_ _everything_ _in_ _it's_ _place._
Sounds great! I'm reading more on "Microcommits" and it sounds like you're following that practice.
helps a lot
i liked and subscribed. thank you
Thanks for the sub!
Is this guy left handed, writing backwards, with a wedding right on his right hand? Or is he right handed, writing forward on glass and mirroring the image later?
....funny, that was exactly my thinking... how do they do it... Maybe to camera perspectives? I think he is right handed and writing forward on glass. The letter "e" looks very clear and easy written... not sure if you could write like this backwards...
Its probably an Piece of Glass hes writing on in the right direction for him and then the Video gets Mirrored so he writes in the right direction for the viewer
They explain it here th-cam.com/users/postUgzf5SL_yh9NglCJzgF4AaABCQ?linkId=86424214
one thing for sure, he is writing from left to right, thus ... right hand
What do you think?
thanks
excellent
Interesting. But what if Bob is in the middle of writing a feature, and Alice submits her modifications? Does Bob have to start from scratch?
No, Bob just needs to pull from the latest version, and make any adjustments to make sure his feature still works, and continue writing it.
Best practice is that Bob has to deal with merging his code. Alice is rewarded for being a good person who submits early and often by it not being her problem. On happy teams, they sit down together for 30 minutes and get it resolved. All the changes are fresh in their minds. No big deal.
Are pushes to the common code base done via a PR or just pushed in?
Great question! What matters is the actual integration into the mainline. PR's slow that process which makes some CI fans anti-PR and the rest of us emphasize the importance of not letting code reviews linger. To get the benefits of CI, it's critical that the reviews are performed quickly to avoid big lags. Pair programming provides the best of both worlds where your partner provides the review in flight making a PR unnecessary.
I have a few questions please ?
Are all programmers working on one very huge monolithic application ? I am confused as coding is very modular these days and just modules need to integrate. API is the main thing along with microcode. So is this for a time before all that ?
If you have several developers working on the same service, this applies without modification.
But as the integration work moves from within a service to mostly across services, it becomes important to very quickly get deployed into an integration test environment and validate the services work together. Alternatively, if you have strong service contracts, getting tests running to validate behavior to that contract is really key. In the same way you wouldn't want a big slice of code to take a long time to merge and have a code level merge conflict, you wouldn't want to work on a microservice for a long time in isolation from other services and then break everybody else with changes to your service.
Same principals, some implementation detail changes. It's a spectrum and you need to find your place along with it.
I know I can trust what he's saying because of the proper software dev attire.
😉 👍
Let's just make 'function' as the basic component of our project, then class, subpacage etc... will be auto generated from the function list, similar node.js, every file will be a module, and even more, we put only one function in the file.
very good explanation for a noob like me
Didn't thought of it in that way. Nicely explained!!!
BTW shouldn't that instead be "If it hurts, keep an eye on it"
Nope. Many things hurt more because delaying them makes them increasingly expensive. Counter-intuitively, doing the painful thing often can make it not be painful because you're not processing a big, stale batch.
The reason it says do it more often is that a lot of the pain depends on the size of the change, and thus the difficulty in finding what to fix.
By increasing the frequency you reduce the size of the change, and thus find the bit that caused the problem in a much smaller change.
Doing version control more often reduces the size of the change, but having long lived feature branches causes merge hell.
Integrating at least daily to mainline gets rid of merge hell, but amplifies the problem of lack of regression tests. Specifically that you tend to write hard to test code.
Adding the regression tests with the new code, and having a ratchet on the code coverage so you cannot commit if it drops the percentage gradually fixes the regression test problem. This also gives you continuous integration if you run all the tests with every commit. However it increases your vulnerability to worthless and flaky tests and to the test suite being slow.
By writing the tests first, you prove that they fail, and then when you add the new code, you prove that they pass, getting rid of worthless tests. Because this speeds up your progress, you have a bigger problem with technical debt.
By adding regression testing to the cycle, you deal with the technical debt, which gives you the red, green, refactor cycle of test driven development.
When most people start writing regression tests, they start with a codebase with one test, does it compile? Then they tend to work from user interface and end to end tests, having lots of trouble because such legacy code is not designed with testing in mind, and thus is often either hard, fragile or just plain impossible to add. This leads to a lot of opposition to testing.
The solution to this is to teach people what real unit tests are before you add the regression testing requirement.
But isn't the merging part done by svn or git. Is a Version-Control just part of continous integration? The other benefit "Testable Build" is also realized by build tools isn't it?If so, what exactly is the CI-Tool like Travis doing?
Hi LasterixTV: CI the practice is a developer activity interacting mostly with source control. The danger of CI the practice is that constant committing leads to continuously broken builds. The CI server like Travis or my baby, UrbanCode Build, is the safety net that is building and testing those commits so that if someone breaks something the whole team knows right away and can fix it before others are negatively impacted. I actually go into some depth on this in a recent blog I wrote on the interplay of practices and technology here: www.ibm.com/cloud/blog/new-builders/technology-and-culture-change-together-the-four-question-framework-for-devops Take care and thanks for visiting the channel, Eric
To the point
I don't get It. Worker A creates new branch from develop. Worker B starts another new branch from develop. Worker A creates some commits. Does CI automatically merge changes to worker b local repo on new branch? How exacly does it prevent merge hell? I don't see solution here.
The key idea is that if A and B go their separate ways for "a long time" the odds of a merge conflict are far greater. The possibility of a massive conflict is greater as well. By integrating their work continuously, they improve their odds dramatically, and if they have a conflict, the conflict is in code that was just written and is still top of mind. Therefore it's easier to address. There's no magic here.
So it's called merge hell. That's the first thing I'm curious when I was learn about Gitflow for the first time. "How do they avoid large merge conflict it?" apparently the can't.
Yeah... Git is relatively good at merging, but the smaller the branch that is alive the shortest period of time is the recipe to minimizing merge hell.
BUT! In both the cases the incomplete code could be committed to avoid merge hell. 🙄🤨
Hola que bueno seria con subtitulo es español
This would've been a good video if it were telling the truth, but the truth and reality is that everywhere I've worked that used CI, had far more merge conflicts (merge hell) than not. Maybe in theory, CI reduces merge conflicts, but in the real world we had even more merge conflicts and worse merge conflicts than the old way. He says that the chances of developers working on the same file is slim - that's also false. Functionality usually spreads out over many files. And even if you don't touch the same files, references, method calls, interface functions and properties, DTOs, and so many other files are shared. So, just because you don't touch the same files doesn't mean you're not stepping on each other's toes and breaking things. Has this guy programmed? He says that CI increases developer productivity. Yeah, right. In addition to fixing merge conflicts, we had to deal with broken pipelines and waste time on that and so on. And you think it is easy for two developers to get together to discuss a merge conflict? One of them is out for the day, or in a meeting, or can't talk because he has a deadline on another project, etc. Now imagine when more than two developers have to work together. We spent more time on pushing our tiles on the board to the right column, merge conflicts, communicating with the QA team, etc. than any actual progress. I've never seen progress move so slow as since companies introduced Agile, CI, and all these other things that were supposed to help. Now, most of the developers focus on maintaining the process and documenting within the process rather than coding. By the time you get back to your code, you have to waste time trying to remember where you left off and what your plan was. I used to enjoy software development because I had chances for creativity and for doing code right. Now I'm just a cog in a machine with the two-week or three-day sprint deadline whipping my back and so many other distractions reducing the quality of my code. I no longer get a chance to interview the stakeholder and the domain expert is just a middleman so I'm getting second hand or third hand misinformation and I don't know how my little piece even fits into the big picture sometimes. Every attempt I've encountered to "fix" the old way has introduced worse cracks and software development has become miserable. It used to be fun. It used to be that I didn't mind working sixty hours a week. Now, I can't wait to get out of there. Any developer can be replaced by another with zero knowledge of software architecture because all they need to know how to do is be part of the process. And when the management also doesn't know anything about software architecture and I see how bad the end product is, and management doesn't even realize how bad it is, and neither do all the developers fresh out of school, then it is truly discouraging. Yeah, tell the truth about CI: the difference between the pretty theory and the ugly truth.
Appreciate your feedback here.
And yes, I programmed - helped Fedex ship cars, American Greetings take returns from retailers, and wrote some CI tools. I've since moved towards more product management type roles.
I would push back a bit and ask "how continuous?" the integration is. How do we get merge conflicts when the other developer is out for the day? It would seem that changes were happening in parallel for longer than a day before a merge.
Several trends in the industry nudge us towards these cycles that are longer than day. GitFlow can delay merges while waiting on code review and is inherently anti-CI. Meanwhile, build times have ballooned with containerization. I'm a fan of Git and containers, but they've kicked true CI in the shins.
And since I've admitted to product management, I'll share that I also hate that PMs often block developers from direct access to customers. Developers should hear about customer challenges directly and frequently. I believe a good PM will guide a development team in picking which of the numerous things we could do will be most impactful. When I've worked with development teams that just wanted me to decide everything, write tickets and let them code against tickets I was very unsatisfied - and the products didn't do great either.
Look, builds should be fast and pipelines should work. Process should be as minimal as possible and as automated as possible. If you spend your life doing Agile theater, everything is going to stink. I'm sorry to hear that you're in a bad spot.
Are you writing backwards on the board?
Hi Ameet...no he's not actually. We wrote this post to explain the technique: ibm.co/2SA1vGd Thank you for watching the video.
@@IBMTechnology the link doesn't lead to the blog
Yes, you have to be able to write backwards to be a software developer
"New code, hey" are you Canadian? :-)
Nope, but I'm married to one.
eye-bee-M ....where, just where could i find this jacket? :)
Hi Marcello! Yes, these jackets are awesome. 😀
You can try our store to see if there are any available: ibm.co/3rYkxHJ
My only question is, how you shoot a presentation like this? Are you writing on a glass?
Hey Hamdi! We shared some backstage "secrets" of our videos on the Community page, check it out here 👉
ibm.co/3xlBkXb 😉
All this time, all I can think of is how is he writing backwards? Did they flip the footage horizontally? Nothing would indicate that in the video because everything is symmetrical. Did he train his hand to write backwards for this video or something? I NEED ANSWERS
Hi there! Here is the answer 👉 ibm.co/3ivJozh 😉
Great video
To people who think he's writing backwards: the video is flipped horizontally. You're welcome 🤦♀️
Thank you so much 😥
its flipped vertically, you're welcome!
The old fashion, he is talking about 1960's.
This was going strong in the early 2000s and I still encounter shops that follow these kinds of approaches. Heck, when I was at Sun in 2002, the guy who got us up to a nightly build was a hero.
Great, so basically an automated snitch!
wow, he can write in reverse
Nah. They flip the video in post-prodcution. I can barely write normally.
Is he writing backwards?
Here's a post we created to explain how these videos are created. ibm.co/335YQYY Hope this helps! --Eric
Yes
why all this guys from IBM are left-hand writers?
Hey there! There's a simple explanation for that. 😉 We shared some behind the scenes of our videos on the Community page, check it out here 👉 ibm.co/3mz5QdP
Man, your backward writing skills are blowing my mind
The handwriting on board is very dated. Just spend times to do a nice PPT, and don't show yourself as a full background picture through all videos.