Tag Info

New answers tagged

1

Most of your issues with Composer can be mitigated: Host a copy of the dependencies yourself. You can even keep them updated automatically via a scheduled git pull. For a large project and/or a corporate environment this is a good step. Use a build system or continuous integration server which creates a production ready bundle you can upload in one fell ...


0

It seems like your main issue with composer is speed. Since so much code is shared between projects, you could have symlinks for shared vendor subfolders so you only need to update in one of the projects and it will update all of them. You can then deploy to all the servers using rsync. I like to have a file with the build version in each project so I can ...


0

For our production websites we install OctoPack (Octopus Deploy) into the web solution via a nuget package in Visual Studio 2013. We set up a Team City build configuration for that project to trigger a deployment with Octopus Deploy, in which we have set up a project and several machines and environments (e.g. staging, live). We use config transforms to ...


2

I think this varies from project to project. Generally the advise by Bart is a valid one. If these assets are directly connected to the source-code and managed by the developer (best example are images statically linked/embedded in a template) it's a good practice to have them inside the repo. If this isn't the case, we have to ask some other questions. ...


1

I recommend you install a continuous integration server, hook it up to your code repository and a snapshot/release repository and automate your builds. This will have a number of advantages: Every component will be versioned when it is released. This includes low-level libraries as well as your final products. Every code commit will trigger a snapshot ...


3

This post makes an interesting point about your question. In a more practical way, if you have 3 components: 2 Consumers: a Front-End and a Mobile App 1 API provider: a Back-End You could use the typical M.m.p (Major.minor.patch) versioning scheme for each but, on your Back-End url you could put something as http://youhost/M.m/resourceURI. As you ...


1

First, I'm lets start off by framing the problem a little differently. You've asked which pieces of software you need to "version". Version is an overloaded term in CS, and could mean about 100 different things. The primary things I would look at is: Version Control - Version control is a configuration management tool that helps you keep track of snapshots ...


6

As you can't control when the mobile apps will be updated to a new release, you need to version at least your REST API. If you don't it will be impossible to make backwards-incompatible changes to that interface. Besides the REST API, it is a good idea to version also the other communication interfaces that go over a network interface. That way, you are ...


1

Some facts: Git is a source control management system, not a deployment tool or configuration management tool There are many stable deployment tools out there: TAR, RPM, Fabric, etc. Ditto for configuration management tools: Puppet, Chef Released history is immutable (the alternative is just crazy) A product is in beta for several commits Conclusions: ...



Top 50 recent answers are included