New continuous integration documentation

I've added a new KB article about our continuous integration setup.

https://staff.vanillaforums.com/kb/articles/140-continuous-integration

It gives an overview of our CircleCI & Chromatic integrations.

Comments

  • This CI stuff seems pretty cool - I'm be curious to know how what the impact is to our own development and how that might provide a benefits to our customers.

    I always love to have more cool dev reasons why Vanilla is the best community software :)

  • The Travis -> CircleCI move was mostly about our developer experience. It's mostly just a better product that runs faster, and has more integrations.

    One of those integrations is mentioned in the article: Chromatic. This is part of us starting to take our UI and theme development a lot more seriously. All new components are going to into this and we are gradually adding older ones. This should drastically reduce the amount of UI bugs that occur as components get added into the new system because developers will be prompted for confirmation if they accidentally make an unintended change.

  • Thanks @Adam Charron this is really helpful.

    From a sales perspective, I'd probably boil this down to something like this:

    At the end of the day, this just makes our development process more efficient and reliable. As a leading community solution provider, we're implementing the latest and greatest dev practices to make Vanilla even better.


    I found something interesting on the web, that I'm sharing below.

    9 Benefits of Continuous Integration

    The benefits of Continuous Integration, Delivery, and Deployment are clear. However, the process to building the pipeline to do Continuous Delivery or Deployment isn’t always easy. But that doesn’t mean you shouldn’t do it. We believe that modern development teams are working their way up to Continuous Deployment. That’s why we suggest getting started with automated testing through Continuous Integration today. With automated tests on each new commit, Continuous Integration is a great way to increase code quality. Here are our top nine reasons why we think every development team should be doing Continuous Integration.

    1. Manual Tests Are Only a Snapshot

    How many times have you heard a team member say “it worked locally.” In their defense, it likely did work locally. However, when they tested it locally they were testing on a snapshot of your code base and by the time they pushed, things changed. Continuous Integration tests your code against the current state of your code base and always in the same (production-like) environment, so you can spot any integration challenges right away.

    2. Increase Your Code Coverage

    Think your tests cover most of your code? Well, think again. A CI server can check your code for test coverage. Now, every time you commit something new without any tests, you will feel the shame that comes with having your coverage percentage go down because of your changes. Seeing code coverage increase over time is a motivator for the team to write tests.3. Increase Visibility Across the Team

    Continuous Integration inspires transparency and accountability across your team. The results of your tests should be displayed on your build pipeline. If a build passes, that increases the confidence of the team. If it fails, you can easily ask team members to help you determine what may have gone wrong. Just like code review, testing should be a transparent process amongst team members.

    4. Deploy Your Code to Production

    A CI system can automatically deploy your code to staging or even production if all the tests within a specific branch are green. This is what is formally known as Continuous Deployment. Changes before being merged can be made visible in a dynamic staging environment, and once they are merged these can be deployed directly to a central staging, pre-production, or production environment.

    5. Build Stuff Now

    All your tests are green and the coverage is good, but you don’t handle code that needs to be deployed? No worries! CI servers can also trigger build and compilation processes that will take care of your needs in no time. No more having to sit in front of your terminal waiting for the build to finish, only to have it fail at the last second. You can run any long-running processes as a part of your CI builds and the CI system will notify you if anything goes wrong, even restarting or triggering certain processes if needed.

    6. Build Stuff Faster

    With parallel build support, you can split your tests and build processes over different machines (VMs/containers), so the total build time will be much shorter than if you ran it locally. This also means you’ll consume fewer local resources, so you can continue working on something else while the builds run.

    7. Never Ship Broken Code

    Using continuous integration means that all code is tested and only merged when all tests pass. Therefore, it’s much less likely that your master builds are broken and broken code is shipped to production. In the unlikely event that your master build is broken, let your CI system trigger a warning to all developers: some companies install a little warning light in the office that lights up if this happens!

    8. Decrease Code Review Time

    You can have your CI and Version Control System communicate with each other and tell you when a merge request is good to merge: the tests have passed and it meets all requirements. In addition, even the difference in code coverage can be reported right in the merge request. This can dramatically reduce the time it takes to review a merge request.

    9. Build Repeatable Processes

    Today’s pace of innovation requires development teams to deliver high-quality software faster than their competition. Modern development teams are building ef cient software delivery engines by creating repeatable processes that standardize development best practices. With automated testing, your code is tested in the same way for every change, so you can trust that every change is tested before it goes to production.