release

To clarify the question : I am looking for established best-practices or a pro/con analysis of known practices by project lifecycle I mean : deploy to pre-integration, integration, QA, preprod and prod environment. For some context: Our project deploys to integration and QA every week, currenlty we create a new release for each integration deployment, but this doesn't feel right. It leads to updating all the poms every week breaking dev level dependencies, forcing every dev to do a refresh of their eclipse configurations. We have large workspaces and eclipse doesn't handle the refreshes so

I am setting our build/release environment using TFS 2017. I set up the Build to run automatically after each commit, and when we are ready to release a version of our application, a Release is manually created, and then deployed to various environments. We would like to tag released versions in our git repository in order to easily know which git revision correspond to a binary. The "Label Source" setting in the Build definition allows to tag a git revision at build time, but since we build on every commit that would generate a lot of tags which we don't care about (as they are not deployed

I have a problem with zipalign. I can't go through the proces. Each run ends with Verification FAILED . For some files i see something like this 2574474 res/drawable-xxxhdpi-v4/abc_btn_radio_to_on_mtrl_000.png (BAD - 2) for the reset 7044070 res/layout/notification_template_media.xml (OK - compressed) The apk is generated but when I upload it via console I receive info that it is not compressed properly. What can I do ? Seems like gradle has pushed a new version without the zipalign task. I had the same issue after changing this: classpath 'com.android.tools.build:gradle:2.+' to classpath 'com

I would like to build and deploy an application which has Django as frontend, YAWS ( appmods ) or Mochiweb/Webmachine as a backend and CouchDB as a datastore. Furthermore, I plan to extensively use CouchDB's ability to replicate in order to provide high fault tolerance for the whole application. I tend to think that in order to achieve this, I must create a single OTP release which has YAWS and CouchDB as Erlang/OTP applications. Does this approach seem to be correct? How can I organize YAWS and CouchDB in terms of OTP applications in order to create a solid production setup? Are there any

I working with a project similar to the project described here . So, it has a few modules in parent pom.xml: <modules> <module>../de.vogella.tycho.plugin</module> <module>../de.vogella.tycho.feature</module> <module>../de.vogella.tycho.p2updatesite</module> </modules> These modules have a general version number e.g. 1.0.0-SNAPSHOT or without -SNAPSHOT . The feature.xml file needs to contain the same version number: <feature id="com.my.feature" label="My plugin feature" version="1.0.0"> and: <plugin id="com.my.plugin" download-size="0" install-size="0" version="1.0.0" unpack="false"/> The files

I'm developing a library for use in other apps and this library has lots of debugging and logging statements thanks to NLog. Is it possible to exclude the reference to NLog.dll when I switch to release mode? Cheers, You can manually edit the csproj file, and do something like this: <Reference Include="NLog" Condition="'$(Configuration)' == 'Debug'" /> This only makes it reference that assembly in Debug. I wouldn't recommend doing this often though, because this behavior isn't reflected in the references list in Visual Studio when you change the configuration. It does work when compiling though