Skip to content

Commit 669ae6e

Browse files
michelle-lunamichelle-luna
authored
Merge pull request circleci#2927 from circleci/tjs/travis-migration
Document Migration from TravisCI
2 parents d798601 + 526bcb5 commit 669ae6e

File tree

2 files changed

+185
-0
lines changed

2 files changed

+185
-0
lines changed

‎jekyll/_cci2/migrating-from-travis.md

Lines changed: 183 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,183 @@
1+
---
2+
layout: classic-docs
3+
title: "Migrating From Travis CI"
4+
categories: [migration]
5+
description: "Migrating from Travis CI"
6+
---
7+
8+
This document provides an overview of how to migrate from Travis CI to CircleCI.
9+
10+
The example build configurations referenced throughout this article are based
11+
off this [example JavaScript
12+
repository](https://github.com/CircleCI-Public/circleci-demo-javascript-express/blob/master/.circleci/config.yml).
13+
For context (and limiting the scope of this article), consider the
14+
example repository's owner to want to achieve the following with their
15+
Continuous Integration tooling:
16+
17+
- On pushing code: run a build and run all tests.
18+
- Expect that build time will be reduced by caching any dependencies after the
19+
initial build.
20+
- Enable the safe use of environment variables.
21+
- On each build, upload a `test-results.xml` file to be made accessible online.
22+
23+
## Prerequisites
24+
25+
This document assumes that you have an account with CircleCI that is linked
26+
to a repository. If you don't, consider going over our [getting started guide]({{ site.baseurl }}/2.0/getting-started/).
27+
28+
## Configuration Files
29+
30+
Both Travis and CircleCI make use of a _configuration file_ to determine what
31+
each Continuous Integration provider does respectively. With Travis, your
32+
configuration will live in a `.travis.yml` file in the root of your repository.
33+
With CircleCI, your configuration will live in `.circleci/config.yml` at the
34+
root of your repository.
35+
36+
## Building on Pushing Code
37+
38+
The example repository linked above is a basic application for creating, reading, updating, and deleting articles. The
39+
app is built with the `MERN` stack and there are tests present on the client as
40+
well as the REST API that should run whenever code is pushed.
41+
42+
To get tests running for this example repository, the beginnings of a simple
43+
Travis Configuration might look like the following example:
44+
45+
```yaml
46+
language: node_js
47+
services: mongodb
48+
before_install:
49+
- npm i -g npm@5
50+
node_js:
51+
- "5"
52+
cache: npm
53+
```
54+
55+
For basic builds, a TravisCI configuration will leverage a language's best known
56+
dependency and build tools and will abstract them away as default commands
57+
(which can be overridden) in [a job lifecycle](https://docs.travis-ci.com/user/job-lifecycle/#the-job-lifecycle). In this
58+
case, when the build runs, TravisCI will automatically run `npm install` for the
59+
`install` step, and run `npm start` for the `script` step.
60+
61+
If a user needs more control with their CI environment, TravisCI uses _hooks_
62+
to run commands before/after the `install` and `script` steps. In the example
63+
above, a "before hook" is used to specify that the npm version be pinned to `5`. Hooks can execute shell
64+
scripts as well, which users will sometimes store in a `.travis` folder at the
65+
root of their repository.
66+
67+
The following CircleCI configuration to achieve the same results is excerpted from the example repository:
68+
69+
{% raw %}
70+
```yaml
71+
version: 2
72+
jobs:
73+
build:
74+
working_directory: ~/mern-starter
75+
docker:
76+
- image: circleci/node:4.8.2
77+
- image: mongo:3.4.4
78+
steps:
79+
- checkout
80+
- run:
81+
name: update-npm
82+
command: 'sudo npm install -g npm@5'
83+
- restore_cache:
84+
key: dependency-cache-{{ checksum "package.json" }}
85+
- run:
86+
name: install-npm-wee
87+
command: npm install
88+
- save_cache:
89+
key: dependency-cache-{{ checksum "package.json" }}
90+
paths:
91+
- ./node_modules
92+
- run:
93+
name: test
94+
command: npm test
95+
```
96+
{% endraw %}
97+
98+
In the config above, no _language_ is specifically required, and the
99+
user is able to specify any number of `steps` that can be run, with no
100+
restrictions on step order. By leveraging Docker, specific Node.js and
101+
MongoDB versions are made available in each `command` that gets run.
102+
103+
### Caching Dependencies
104+
105+
With CircleCI you have control over when and how your config caches and restore dependencies. In the above example, the CircleCI `.circleci/config.yml`
106+
checks for a dependency cache based specifically on a checksum of the
107+
`package.json` file. You can set your cache based on any key (not just `package.json`) as well as set a
108+
group of cache paths to defer to in the declared order. Refer to the [caching
109+
dependencies document]({{ site.baseurl }}/2.0/caching/) to learn about customizing how your build
110+
creates and restores caches.
111+
112+
In a Travis Configuration, [dependency
113+
caching](https://docs.travis-ci.com/user/caching/) occurs in your build after the
114+
`script` phase and is tied to the language you are using. In our
115+
case, by using the `cache: npm` key in `.travis.yml`, dependencies will default
116+
to caching `node_modules`.
117+
118+
### On Using Containers
119+
120+
With CircleCI, the context in which your checked out code executes (builds,
121+
tests, etc) is known as an [Executor]({{ site.baseurl }}/2.0/executor-intro/).
122+
123+
If you're coming from TravisCI, using Docker will be the closest means to running
124+
a build based on a language. While you can use any custom Docker Images, CircleCI maintains several [Docker Images]({{ site.baseurl
125+
}}/2.0/circleci-images/) tailored for common `.config` scenarios.
126+
127+
## Environment Variables
128+
129+
Both Travis and CircleCI enable the use of environment variables in your builds.
130+
131+
In your CircleCI `.circleci/config.yml` you can put environment variables directly in your
132+
build config in a step, a job, or a container. These variables are public and unencrypted. With TravisCI, it is possible to include [encrypted environment](https://docs.travis-ci.com/user/environment-variables#defining-encrypted-variables-in-travisyml) variables directly in your config (if you install the `travis` gem).
133+
134+
### Setting Environment Variables in the Web Application
135+
136+
If you've used TravisCI's [repository settings](https://docs.travis-ci.com/user/environment-variables#defining-variables-in-repository-settings),
137+
you'll be comfortable setting your environment variables in CircleCI's project
138+
settings page. Read the docs for setting environment variable in a [single
139+
project]({{ site.baseurl }}/2.0/env-vars/#setting-an-environment-variable-in-a-project).
140+
141+
With CircleCI, it is also possible to securely set environment variables across _all_ projects using [contexts]({{site.baseurl}}/2.0/contexts/).
142+
143+
**Note:** CircleCI has several [built-in environment variables](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables).
144+
145+
## Artifacts Uploading
146+
147+
With TravisCI you can upload build artifacts either manually using AWS S3 or
148+
as an attachment to a Github Release.
149+
150+
On CircleCI, artifact uploading occurs in a step in your config:
151+
152+
```yaml
153+
- run:
154+
name: test
155+
command: npm test
156+
- run:
157+
name: code-coverage
158+
command: './node_modules/.bin/nyc report --reporter=text-lcov'
159+
- store_artifacts: # < stores test-results.xml, available in the web app or through the api.
160+
path: test-results.xml
161+
prefix: tests
162+
- store_artifacts:
163+
path: coverage
164+
prefix: coverage
165+
- store_test_results:
166+
path: test-results.xml
167+
```
168+
169+
After an artifact is successfully uploaded, you can view it in the Artifacts tab
170+
of the Job page in your browser, or access them through the CircleCI API. Read the
171+
documentation on [artifact uploading]({{site.baseurl}}/2.0/artifacts/) to learn more.
172+
173+
## Advanced Tooling
174+
175+
More advanced configuration on Travis might make use of a *Build Matrix*
176+
(a configuration that specifies running multiple parallel jobs) or *Build Stages*
177+
(grouping jobs into stages that can run in parallel as well as having sequential
178+
jobs rely on the success of previous jobs.)
179+
180+
With CircleCI you can use [workflows]({{site.baseurl}}/2.0/workflows/) in your `.circleci/config.yml` to define a collection of jobs and their
181+
run order, whether leveraging parallelism, fan-in or fan-out builds, or
182+
sequentially-dependant builds. Workflows allow complex and fine-grained control
183+
over your build configuration.

‎jekyll/_data/sidenav.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -44,6 +44,8 @@
4444
link: 2.0/ios-migrating-from-1-2/
4545
- name: Using the config-translator
4646
link: 2.0/config-translation/
47+
- name: Migrating from TravisCI
48+
link: 2.0/migrating-from-travis/
4749

4850
- name: Configuration
4951
icon: docs/config.svg

0 commit comments

Comments
 (0)