I’ve been a long time Jenkins user and I find that I’m having a very hard time transitioning from its arbitrary-job-runner model to Travis’ gitops-centric model. I can’t seem to wrap my head around creating a single .travis.yml file that can do everything my multiple Jenkins jobs did. I’m sure I can do it, I just can’t conceive of what the travis file’s structure might look like. The path looks something like this:
- On every commit, we build the code and test - that’s easy enough
- On every merge to main, we build, test, push the built docker image to ECR, then deploy it to our dev integration server, then run a few UI tests as a sanity check
- When a tag is created, we build, test, push to ECR as a named release, and deploy to staging
- Lastly, once the application has been blessed in staging, we deploy that same release to production - i’m not even exactly sure how to trigger that Travis, much less add it to the structure of my file.
What I’d love some help with is the basic structure of a .travis.yml file that targets those actions - at least as far as staging since, as I mentioned, I’m not yet even sure how to tell Travis that I’m ready to go to production.
I assume that once I have a feel for one or two of the “sections”, the rest will start to come together, but getting beyond the build section has proven a bit of a challenge. Every bit of Googling I’ve done has only produced simplistic examples that make it difficult for me to extrapolate into a wholistic process.
I’d really appreciate any help I can get or any resources that might prove more useful than the Travis docs have been. Something that…puts it all together, i guess.
For reference only, since there isn’t much, my current .travis.yml file looks like this:
os: linux
services:
- docker
script:
- docker build .
Obviously only handling a very basic build process, but it’s a place to start.
Thanks.