14

First, while Docker is sometimes seen and used as a ad hoc packaging system, it actually solves a totally different problem: Docker is about running programs. The Docker system allows to describe services, that can be scaled at will and to control swarms of containers. Debian packages are for installing programs and they are able to handle dependencies ...


10

In such context the typical advice should be immediately applicable: use the right tool for the job. But then you also cannot ignore nowadays the almost virulent tendency of software tools to extend functionality into more or less related fields and actually become toolsets for various reasons: cool feature(s) to have, expand customer base, amass more ...


8

I would integrate the schema management into the application itself (or along with it). Any change to the schema should be committed along the application code (and hence tagged also). There's already a bunch of possibilities listed in this question: What practices or tools enable Continuous Deployment of Databases With this kind of tools, using an in ...


8

It is a fascinating question for which real answers may not actually exist; I appreciate that while you tried to keep the question contextualized on the VCS, it naturally scaled by itself up to infrastructure design and implementation planning. Though, it seems many of us are working of this kind of transitioning, which can be exciting, but at the same time ...


8

There are a few different ways to achieve goals of this sort, each with some different tradeoffs. I'm going to describe the most common ones below. The simplest approach is to use Terraform's create_before_destroy mechanism with autoscaling groups. An example of this pattern is included in the aws_launch_configuration documentation. In this scenario, ...


7

Let's assume you have the following scenario: You have many customers, but most use the exact same app, except for some configuration changes. You would like each of your customer to get the latest of the app ASAP. If this is your scenario then try make everything that needs to be differentiated between the apps a configuration change. You build one (or one ...


7

Mainly an artifact is the result of of a build phase, this mean a package is an artifact of a kind. A package is usually a way to install a software or application, it includes the software itself and some intelligence to setup and configure the software. Calling an artifact a package usually comes when the artifact (whatever it is, from a .deb to a simple ...


7

Vagrant is for setting up test environments right? Ansible/Chef etc. seem good for servers you own, but what about cloud? Docker... great for standardizing app, so why use Ansible/Chef? Kubernentes.. good for deploying to multiple environments and scaling Just a personal note: the way you formulate these things makes me assume that you are diving freshly ...


6

Configuration management tools are used to get a system into a known state. Deployment tools deploy new program files and program data to a system. At the end of the day, both types of tools do some combination of: Determine the current state of the system. Transfer files to the system. Add or change persistent data (e.g. configuration files, database data,...


6

Fabric (and Capistrano, presumably the unnamed Ruby tool you came across) are a bit unusual in that they're task runners with extra features for easily running tasks on remote hosts. I'm not aware of any other popular tools that do exactly the same thing, but depending on your needs there are a few other options that may work for you. Grunt and Gulp are ...


6

There are many tools that can do something like this, including configuration management tools like Chef, Ansible, or Puppet; and KVS tools like Consul and etcd. You could also integrate it as a build step in your CI server, or sidestep the issue using live configuration at runtime against an external configuration store (again, something like Consul or etcd,...


6

For software in the web app category, depending on you infra/hosting provider such decoupling might be possible to switch incoming traffic across (or split it between) different deployed versions of the sw, practically covering any of the changes you mention: bugfixes, visuals, etc. Such support would typically not require feature toggles. And it might be ...


6

I don't think there is a generic term for promoting to production. I can tell you that within the devops community, terms are frequently interchanged. As long as the point being addressed is well thought out and made clear, the point can be understood. Some of the terms that are used when referring to the movement between environments are deploy, propagate, ...


6

In short, I see two categories of tests for your infrastructure: 1) does it have everything you need to run your application and 2) does it not have any superfluous stuff. First and foremost, you can treat the test suite of your actual software as a kind of "meta test" for your infrastructure. As long as you create the infrastructure from scratch for each ...


6

Such question could be an indication of a poor architectural slicing into microservices. From What are Microservices?: These services are built around business capabilities and independently deployable by fully automated deployment machinery. The key point missed in such case would be their independently deployable aspect. The point could also be ...


5

Websockets don't really have any handling for this per se. You could build your own system but generally the idea for HA is that if anything happens you'll set the client up to automatically reconnect. There will be some non-zero downtime during a blue-green swap but if your app is well built it should handle that already. If you wanted something more ...


5

With a minimally engineered server code (a Google AppEngine application in the example) it's possible to duplicate and forward incoming HTTP traffic received by a production server to a test server (or vice-versa) for the purpose of comparing their responses. See https://stackoverflow.com/questions/38799566/can-i-asynchronously-duplicate-a-webapp2-...


5

A Debian (or RedHat) package to install applications has been a good practice when done correctly. Packages are used for the purpose of deploying applications which are infrequently changed. Debian packages involve some overhead, like version management, dependency management, pre&post-install scripts, etc... In many cases upgrading from some older ...


5

Instead of using Travis' deployment features, build the deployment logic in to your normal "test" script(s). For a PaaS this might be as simple as pushing to another git remote if all tests pass, but the sky is the limit.


5

It is convenient to use Environment Variables to provide runtime configuration for such scripts. Especially when it contains secrets that you don't want to hold in any persistent storage or in version control. When you do actually have secrets, it is even better to use some kind of secret management system that will provide these secrets on request. One ...


5

Alright... you're not going to implement every tool or automation at the same time, as some of them have quite deep impact on your development processes (and I daresay, development culture). Take a step-by-step approach; research each individual tool. Figure out what it actually does, what it is useful for. Play around with them, install them locally, go ...


4

Yes, there's drawbacks. With a .deb package you won't be able to have two version of the same application on the same host. You will have to rely on the distribution available packages, if your app rely on nodejs for example, either you'll be stuck with the distribution version or you'll have to install your own. Now when you want to host multiples ...


4

Travis CI supports deployment on branch release by using the following syntax: deploy: on: branch: release The problem is that GitHub does not support it. As per GitHub Releases Uploading page at Travis CI: Please note that deploying GitHub Releases works only for tags, not for branches. For GitHub the only workaround is to push tags (e.g. git ...


4

Proper management of an application's secrets has always been a challenge. New challenges came with the adoption of the cloud. There's a great OWASP presentation about the reality and challenges of storing secrets in the cloud. You might be surprised to hear that storing secrets into the source code is one of the solution (or "architecture") presented. That'...


4

While with monoliths you might be restricted to switches, with microservice architectures, you can split every deployment pool of nodes providing a service (ie. pods). You then activate the deployment of the newly changed product in a subset of pool, and carefully monitor it; you can even choose which amount of the pool to deploy the change to, say for ...


4

TL;DR: Just use Ansbile, it is both configuration and deployment tool :) There are several types of deployment: Application based (files, archives packages) Container based (includes VMs, Habitat, LXC, Docker) Function based (Micro services / Lambdas / Functions) I assume in this case we speak only about application updates on server(s). For deployment ...


4

What are the general ways to tackle this problem? The ideal way to resolve your problem would be to dockerise your application, as it would remove any worries you have about compatibility between your build and running servers. Installing dependencies using pip in a Dockerfile is trivial, and as long as you're deploying the same container image you never ...


4

As of you are using Rancher the easiest way would be to register custom Rancher Catalog and create an item for each stack/service you want to deploy. Rancher Catalog is a Git repository with the following structure Then in Jenkins you can create a job that would call Rancher REST API to deploy/update stack/service. In its turn Rancher would pull latest ...


4

From my standpoint the best approach would be to: Separate build process using Jenkins that would build NodeJS project into distribution and wrap it into Docker image Spin up Docker registry that would accumulate Docker images from Jenkins (this registry should be accessible from Kubernetes cluster) Move environment variables to Jenkins secrets or use ...


4

Assuming there are no changes in Master that are not in your release branch and you don't rebuild after you merge the code then you could deploy first and then merge to master. If either of those are not true, then merging first would be more common. The process depends on how you handle your branching strategy. If other things could be merged into ...


Only top voted, non community-wiki answers of a minimum length are eligible