Popular posts

CI/CD ?? and the idea seems somewhat similar to the webhook solution mentioned above, just a bit more sophisticated... Would you mind giving me more details about this method?

CI/CD stands for continuous integration/continuous delivery. It's a software engineering approach used to automate the process of building and deploying an application. And, yes, it's nearly identical to the solution Joe suggested. Most CI/CD servers will use something like webhooks. If you took his approach, you'd be effectively making your own primitive CI/CD server.

CI/CD servers will have a pipeline of lifecycle events like install dependencies, build, test, and deploy. The server can monitor a repository (usually by means of a webhook) to kick off the pipeline based on certain conditions such as a commit to the master branch.

The continuous integration part of CI/CD servers is responsible for monitoring commits to a repository. When the server detects a commit, it will kick out the first lifecycle events. This pipeline will usually start with a pristine environment. Because you should only, in general, be committing source files to version control, the first stages of the pipeline is to install dependencies and to build your source code (in simple applications, you may not have much of a build step). The next lifecycle event is to run automated tests. If the automated tests pass, the pipeline can advance to the next stage.

Ideally you shouldn't commit changes to a main branch like development or master but instead to a feature branch. Let the CI/CD server merge the feature branch into the main branch only when your automated tests have passed successfully. (Many software engineering shops will add a code review stage before continuing with this merge.)

The continuous delivery part takes over next. If the build is occurring on a main branch such as master or a release tag, the server will proceed with the deployment stage. In this stage the server could upload files to an FTP server, start a Docker container, or, like in your case, update a remote application and restart it. The server will again report back whether the deployment stage was successful. Hopefully you get the green light.

Travis is a particularly convenient CI/CD server because all you need to do include a build configuration file in the root of your project and to hook up Github to Travis (Github is probably even showing you a message on the pull request page about doing so). Example:

.travis.yml

dist: trusty
language: node_js
node_js:
- '8.7.0'
branches:
  only:
  - master
  - development
  - /\d+\.\d+\.\d+/
before_install:
- bash support/travis/initialize_env.sh
install:
- npm install
script:
- npm run build
test:
- npm test
deploy:
- provider: s3
  bucket: my-bucket
  local-dir: dist
  upload-dir: preprod
  on:
    branch: master
- provider: s3
  bucket: my-bucket
  local-dir: dist
  upload-dir: prod
  on:
    tags: true

Very intriguing. I am really excited to try this out. I guess this all falls under devops, right?

Sort of... build engineering is more appropriate. Devops tends to refer to managing infrastructure, like virtual machines, clusters, load balancers, etc. These days devops engineers usually work a lot with cloud platforms like AWS, Azure, Google Cloud Platform, etc. But a devops engineer could fill the role of build engineer pretty well.

The skills of a build engineer or a devops engineer are some of the skills that you don't usually learn in school but are very important to know as a software engineer. It's definitely worthwhile to learn them now. You'll be ahead of your peers if you do.