Should I push my Meteor build to version control?

deployment
1

I’m setting up CI / CD for my Meteor project, and I don’t know if I should have my runner Docker container download the raw Meteor project and then build every time, or if I should build in the dev environment and push that build to git.

Not sure what is best practice, or the pros and cons of each.

Everywhere I look, tutorials are pointing to the meteord docker image, but this doesn’t seem to support building - only running of an existing build.

2

I’m always building the project once, but put the artifact as a zipped file in a file storage like s3. All servers that require the built version will fetch it from s3 and then unzip it and start it.

The wins in this are:

  • No fetching of external dependencies
  • Building costs server resources. More then running the actual app. This allows to build on a big server and stop that server after the build
  • Faster autoscaling because no rebuilds are needed.

Git repos can always be an option but its not meant for just storage. Its overkill. But then again if its for your needs the shoetest amount of time and the simpelest step. Why not?

3

Okay, thanks for that!

I’m really just looking for what’s normally done. Like the standard action.

4

@cloudspider - have you rolled any scripts for your build+zip+store process that you can share?

5

Yes, I can share some. Not near my laptop now. Please tag me if I forget to post it here within 24 hours! @wickedmuso

6

@wickedmuso @dthree
Ok so here it is. I will just share it here initially and later on create a small tutorial with some background info and knowledge. The below script is part of my continuous integration flow. It is the first step in 2 phases. Build and deploy. Build takes a meteor project directory, runs the installers, runs unit and integration tests, builds it and creates a tar file from it. The deploy step then takes the tar file, puts it on a server and runs it using a node guard like pm2 or forever.


#!/bin/bash

# Remove old build file if it exists
cd $WORKSPACE
file='build.tar.gz'
if [ -f $file ] ; then
    rm $file
fi

# Navigate to project root
cd ./src

# Install meteor dependencies
meteor npm install

# UNIT TEST PLACEHOLDER: This is where you trigger your unit tests if needed
# INTEGRATION TEST PLACEHOLDER: This is where you trigger the integration tests if needed

# Build meteor to node using the build tool. Build as directory
meteor build $WORKSPACE --directory

# Navigate to the built folder
cd $WORKSPACE 


# Copy in some non-meteor things like for example a cron triggered script

cp -R ./jobs/ $WORKSPACE/bundle/jobs


# Run npm install in bundle (if needed for non-meteor stuff)
cd $WORKSPACE/bundle && npm install --ignore-scripts

cd $WORKSPACE/bundle/programs/server && npm install

# Goto bundle location
cd $WORKSPACE/bundle

# End to End TEST PLACEHOLDER: I have this running on a different build step. 
# That step is to pull the tar file, untar it and start it.
# Important is to understand that e2e happens after build. E2e includes UI crawlers 
# with for example Selenium using cucumber.

# Create tar file
tar zcf  $file * 

# Push file somewhere. I have a push to S3 script which is essentially just a jenkins plugin
1 Like
7

If you or someone else wonders, I’ve posted a step by step to build a docker image containing the bundled app for easy deployments. You can read more here Getting your daily work done with MeteorJS

1 Like