Rightly named as funfunfunction. Although not my first video but this was a laughter burst when that coffee break happened and this burst happened while I am very seriously watching on my office PC :D Thanks for another exciting video.
Come on, it's always a bit different and if it annoys you you can anyway skip it but it's perfect for my monday mornings where I usually would be a bit grumpy :D
Used the link for home project, and i completely love the idea of "CI as a service". Was simple and easy to configure and implement a java project which uses JavaScript as frontend! Thanks!
Thankyou for using Version 2! I experimented with migrating some of my newest projects from 1.0 to 2.0 just before this video. Being new to docker it's kind of a stretch of the mind.
I would definitely like to see a future video talking about npm install times, caching, etc to speed up that bottleneck. Also, I love your videos so much!
Thanks, for your job, MPJ. Here the shortcut for changing remote url "git remote set-url origin your_url" Also, for those, who likes using terminal for git commands, there are git aliases - real timesavers (git-scm.com/book/en/v2/Git-Basics-Git-Aliases)
@mpj you have great videos but this one is missing out on a very very important piece of information. The only reason you are able to pull off `npm test` in your circleci scripts is because the project you have demonstrated has a built in browser ('PhantomJs'). I would like everyone to understand the need for a browser when conducting CI on front end apps. If you have no browser baked into your project, you should use CircleCi's `-browser` suffixed images as the image comes with a browser.
Hello Mattias, I have set up an environment variable locally and process it using 'dotenv' npm module. Circle CI is running my server but it is not able to recognize my environment variable and thus failing my REST Api test. Could you please help me set up environment variables on circle ci ?
2.0 Docs Welcome to CircleCI 2.0 documentation! Included here are tutorials, samples, and reference documentation for CircleCI version 2.0 in the following two sections: circleci.com/docs/2.0/ Developers: Instructions for configuring a CircleCI YML file to automate your builds, tests, and deployments using the hosted CircleCI application. Server Administrators: Instructions for installing and maintaining CircleCI on your local server or private cloud. This page describes how to run your first green build.circleci.com/docs/2.0/
YARN! lol... But seriously, I am wondering if there is a good reason why you chose not to use it? It's very much faster in every case I've used it. Does it not work with CircleCI?
+BeheadedKamikaze there is a very marginal speed improvement over npm5, and yarn makes sacrifices so it's not directly comparable. I did not like yarn pre-npm5 either since I think the tool doesn't offer enough improvement to make up for the balkanization it introduces. It's so fucking annoying to teach new JS devs right now because you end up on this little bump where you have to explain the state of package managers while you are trying to teach them something completely different. It also perpetuates the image other programmers have of the JS community that we jump on we tooling like squirrels with ADHD.
+funfunfunction thanks for the reply - I will have a look at npm5. Yes a lot of people complain that there is tooling overload, and steep learning curves, so many tangents while trying to learn something about the language. Reducing the amount of 'required' tooling would be a good thing!
Keep up the great work! Also it hurts me when I see you typo'ing those git commands. Maybe using the visual code studio git integration would be a better idea? Pretty simple and easy :))
+Khanh Huynh Tran I like that I can use it for free for my private personal projects, that it's so incredibly polished, and that it's pushing docker so hard. The new workflow stuff also looks promising but I have less experience with that and don't know how it compares to other offerings.
Thanks for the great introduction to circle CI. I, however, need to modify circle.yml file to allow developer builds to occur on circle only if the commit message contains 'circle' word in it(which is to be checked by a shell script). I have read the docs and configuration information of circle CI but found nothing related to it. Please tell me how to do this.
"partly because CircleCI is sponsoring this video, but also, it's my personal favorite" ... that just came out wrong ... nobody in their right mind can believe the second reason, just because of the first.
@funfunfunction great video. I understand this episode is sponsored by CircleCI. If you had to convince me to use CircleCI instead of Travis CI, what would be your strongest argument?
+Philippe Vaillancourt It is very context dependent. There are many reasons why you'd pick one over the other. Without knowing any context I'd usually just say that it has a free tier for private projects, which Travis doesn't have.
My typical response, try both of them. If you have a public project, you can try both for free and see which you prefer. For a private project, you can't use Travis CI for free but you can at least try CircleCI first. Docker-centric builds, integration with both GitHub and Bitbucket, and simply performance are major differentiators. Build a project that is intensive on both Travis CI and CircleCI and you'll usually see CircleCI complete the build much sooner.
So what happens with the repo if the circleci build fails? Will it revert the branch to the previous commit? The whole point is that broken code shouldn't be commited to master, right?
You commit to a separate branch and create a pull request. If the build fails, you won't be able to merge the PR into master (assuming you configured github or whathaveyou properly).
Yes, you should never ever push directly to master. As veetek83 has suggested, create a branch, create a pull request, and once the build has passed (and someone has review and approved the PR) ONLY THEN merge it to master. Also, to prevent nasty merge surprises, if the branch has been around longer than a day or two, update it by merging master into your branch and re-push it, make sure it still builds again before merging the PR.
Why shouldn't I push directly to master? One of the biggest issue we have in our industry is jumping on the "new way of doing things because the old ways are wrong". Everything becomes mantra and best practice, with no regard for context. An example of this is: "never use 'new'", and then slap junior programmers on the wrists when they do, yet the reason why and when is forgotten. We were _taught_ that when we were a junior but we never _learned_ why and when. Pull-requests and feature branching was popularized by GitHub. In that context you often have an open source project with lots of disparate people spread out over the world and few trusted members that can push to trunk. It makes perfect sense to use git-flow there. If you are a co-located team, in an office, working on the same thing, pair-programming, talking, discussing and a shared understanding of the product. The utter waste of pull-request and feature branches is apparent when you have just done all that, implemented a feature, and then have to do a branch and a pull request because it was "the rule". In that context it's an anti-pattern making the team avoid things like opportunistic refactoring, etc. and in the end slowing the team down. Of course, if your "team" are a group of individual programmers sitting by their own keyboard with headphones on all day, you're not really a team are you? Then you have bigger cultural issues (lack of cooperation for one) and enforcing rules to MAKE programmers interact through pull-requests is just a band-aid that won't fix anything in the long run. There is nothing to say you can't work with branches locally if you prefer that, but enforcing git-flow because a belief that it "it improves quality" is just... silver bullet thinking. As said at the end here martinfowler.com/bliki/FeatureBranch.html "Paul Hammant may be right: "I wonder though, if a team should not be adept with trunk-based development before they move to distributed."" Everything is context dependent!
Not saying you should use Git Flow... personally I don't like it. But the purpose of branching and pull requests is not because "that's the rule", there are 2 very good reasons: to get other people to review your code, and so that you can ensure that the automated tests pass before pushing your code out to a live server in a continuous integration setup. When doing CI, you don't want a failing master build because it clogs up the pipeline, meaning nobody else can merge their changes until the broken build is fixed. It's much better to isolate those failures onto their own branches where they can be properly triaged and fixed, without impacting anyone else's workflow. You want peers to review your code so that you all know what each other is doing; so that they can point out mistakes that you might have missed; so that they can make suggestions for how to improve or clean up your work; so that they can learn from you; so that you can learn from them... the list goes on. Even when working in pairs it is still good practice to get (an)other human(s) to look at your work. Once you work as part of a mature team for a while you will begin to realise these things for yourself, as I did. These days, I would not want to work anyplace that did not do these things.
I understand that those are the outcomes we are seeking and I agree with them. My issue is that it has become dogma and "the right way" while there may be different, possibly better, ways to achieve the same outcomes. As someone that takes an interest in psychology I can't help reading more into things than what is said/written. Too often we convince ourselves that the reason we are doing something is because _these other reasons_ whether they are or not. Why must master be "pristine"? Why must all changes be reviewed? Do we really get the benefits we think we are getting? Do I really believe these things or were I taught to? We as humans are not as rational as we think we are. Regarding CI; it was never about having the _trunk always working/never failing_ - the whole point of CI is to provide feedback that something needs to be fixed. No one in the team should really be working on anything else but fixing the build as long as it is broken. It is more about optimizing for keeping the product in a releasable state, not local optimization around individual task, user stories, burndown/velocity, etc. Oh, and the team will fast learn code-hygiene and how to work well after breaking trunk a couple of times. Trunk-based development enforces learning and code-hygiene while feature-branching may do just the opposite. There are other ways of peer-reviewing besides using pull-requests, for example using RFCs and reviewing after the fact. If the team have good engineering practices, good CI/CD and good manual exploratory testing this will be fine in most cases. This lets the team focus their reviews on the more sensitive areas in the code-base and adapt as new troublespots are found. All this takes maturity, hygiene and care. In the end it boils down to one simple thing: trust.
What you saw was CircleCI asking what environment do you want your builds to run in on our servers. Majority of the time the answer will be Linux. You'll want to use macOS when you're building something that is required to run on macOS such as building an iOS app that uses XCODE and other Apple-native tools.
