Tag Info

New answers tagged


Depends on your platform. There are standard solutions for RedHat and Debian as rpm and deb packages respectively. For windows there's nuget and chocolatey and in general most programming languages have sanctioned packaging systems like python's eggs and ruby's gems with tools like virtualenv and bundler that help managed those packages. I would also look ...


Having a branch per customer is not an ideal solution, for a couple of reasons: It doesn't scale well. You will have to create a new branch for each customer, and then manage merging code changes between all those branches. And, when you actually do need a branch for a legitimate reason (feature branch, production fix, etc.), you'll have to branch all ...


You are asking the wrong question. »How often should internal applications be deployed« has many implications which are disadvantageous - e.g. if you have a release-cycle - say 1 week - there are perhaps small but important changes, which have to wait 6.x days to the next release. It would be a better practice to release as often as you have something to ...


In the world of commercial software, release schedules are tied to: Development timeline (How long does it take to create each release or patch?) Testing and QA timeline (How long does it take to test, qualify, and certify the app as running properly on all the platforms and in all the modes in which it will typically be used; this often includes ...


I strongly suspect that the answer will be entirely dependent on how painful (or painless) it will be to upgrade 30 people to the newer version. The easier you make it to upgrade, the better off you will be with a rapid release schedule. The more painful it is, the more you will benefit from a regular release schedule. It's completely up to you.


I would suggest you to take a look at Spring Boot. It can save you a lot of configuration. They have a lot of archtypes with different technology stack combinations out of the box. Such app lightweight can be deployed anywhere. You can still switch from embedded Tomcat/Jetty to hosted alternative at later stage. It is new opinionated way to build Spring ...


If it's going to happen frequently on the application itself then you want to use native code. Yes, PhoneGap and Xamarin style products aim to allow you to write cross-platform mobile applications easily...but they are not 'lightweight' to add to an existing entirely native codebase. You can explore Xamarin - it would likely be a better fit than PhoneGap. ...


If you don't need additional layer such as Fabric: Copy files to the server using scp, including the script to run, Run the script through ssh. In both cases, make sure you don't store SSH password anywhere, but use a pair of private/public keys.


Fabric can be used to run basic deployment commands (and configuration management tools such as Puppet or Chef) for a very nice SSH-based deployment process.

Top 50 recent answers are included