We are changing our technology from c# to Java. We are using IntelliJ Community Edition as IDE. While using Visual Studio, we have custom check in policies to avoid developers from doing things we don't want according to our standards. We also want this for IntelliJ before commits. We want to protect our project structure according to our standards. Is there any way to realize my this wish?
That is generally possible, but implementation depends on the VCS in use.
E.g. in Git, one can use local (to verify on commit, e.g. pre-commit) and server-side (to prevent pushing incorrect changes, e.g. pre-recieve) hooks.
IF TFS is used, existing TFS integration plugins allow implementing custom Checkin policies as additional custom plugins. There are some implemented already
Related
Recently I started to incorporate good practices in my development workflow, so I split the development server and the production one. I also incorporated a versioning system using Subversion (Tortoise SVN).
Now I have the problem of synchronize the production server (Apache shared hosting) with the files of the last development version in my local machine.
Before I didn't have this problem because I worked directly with the server files through Filezilla. But now I don't know how to transfer the files in an efficient way and what are the good practices in this aspect.
I read something about Ant and Phing but I'm not sure if this appropiate to me or is unnecessary complexity.
Rsync is a cross-platform tool designed to help in situations like this; I've used it for similar purposes on multiple occasions. This DevShed tutorial may be of some help.
I don't think you want to "authomatize" it, rather establish control over your deployment and integration process. I generally like SVN but it has some bugs and one problem I have with it is that it doesn't support baselining -- instead you need to make a physical branch of your repository if you want to have a stable version to promote to higher environments while continuing to advance the trunk.
Anyway, you should look at continuous integration and Jenkins. This is a rather wide topic to which not a specific answer can be given. There are many ins, outs, what-have-yous. Depends on your application platform, components, do you have database changes, are you dealing with external web services or 3rd party APIs etc.
Maybe out there are more structured solutions but with Tortoise SVN you can export only the files changed between versions in a folder tree structure. And then, upload as always in Filezilla.
Take a look to:
http://verysimple.com/2007/09/06/using-tortoisesvn-to-export-only-newmodified-files/
Using TortoiseSVN, right-click on your working folder and select
“Show Log” from the TortoiseSVN menu.
Click the revision that was last published
Ctrl+Click the HEAD revision (or whatever revision you want to
release) so that both the old and the new revisions are
highlighted.
Right-click on either of the highlighted revisions and select
“Compare revisions.” This will open a dialog window that lists all
new/modified files.
Select all files from this list (Ctrl+a) then right-click on the
highlighted files and select “Export selection to…”
Side note:
You have to open more details about your workflow and configuration - applicable solutions depends from it. I see 4 main nodes in game: Workplace, Repo Server, DEV, PROD, some nodes may be united (1+2, 2+3), may have different set of tools (do you have SSH, Rsync, NFS, Subversion clients on DEV|PROD). All details matter
In any case - Subversion repositories have such thing, as hooks, in your case post-commit hook (executed on Repository Server side after each commit) may be used
If this hook (any code, which can be executed in unattended mode) you can define and implement any rules for performing deploy to any target under any conditions. You must only know
Which transport will be used for transferring files
What is your webspaces on servers (Working Copies of just clean unversioned files - both solution have pro and contra sets) - it will define, which deployment-policy ("export" or "update") you have to implement in hook
Some links to scripts, which export files, affected by revision (or range of revisions) into unversioned tree
I'm wondering if there are any existing tools that allow for management on configuration properties (like Java properties files, or other similar formats) in the same style as database migration tools like liquibase and flyway.
I'd like a better way of managing my application's configuration properties which would allow me to track their evolution over time.
Does something like this exist?
Isn't it enough if all config is externalized and version controlled? Tracking evolution then is just a matter of version history. Unlike db migration scripts, config doesn't execute to upgrade something to version x to verion y. The continuous delivery book says:
Generally, we consider it bad practice to inject configuration
information at build or packaging time. This follows from the
principle that you should be able to deploy the same binaries to every
environment so you can ensure that the thing that you release is the
same thing that you tested.
And then there is this advice to store it all as environment variables.
Are there any tools available to run pre-commit builds for Perforce and auto submit changes on successful execution?
I'm looking for a server side solution (unlike JetBrains teamcity VS addin which does it from client + has some others limitations like inability to add a job id) which can also queue up multiple check-ins
I think Electric Commander has a pre-flight capability. Might be worth a look. Otherwise you can use a change-content trigger to intercept a commit, invoke a build process with the changed files,
and then approve or reject the submit.
We use ProofBuild. I use it in a specific configuration that doesn't do automatic check-in (only checks that the changelist is good), but ProofBuild supports this automation too.
In subversion, hooks are written on a per-repository basis. Each hook is written in a descriptive filename (e.g. pre-commit) in a folder named "hooks" at the root of the repository. According to the BZR docs, hooks are typically installed globally (e.g. in the ~/.bazaar/plugins/ directory).
Is it possible to create, say, a pre-commit hook that is committed to the branch and that runs without a user having to install a plugin?
I see in the docs and in some code discussions a reference to something called "branch hooks," which sounds promising.
I found this blog: http://schettino72.wordpress.com/2008/01/20/how-to-execute-tests-on-a-bazaar-pre-commit-hook/, which quotes:
"plugins in bazaar are not project
specific. so you cant control in which
projects (branches) your plugin will
be applied (it will be applied to
all)."
which is less promising. The blog gives a workaround in that you write and install a plugin that calls hooks in your repository if they exist. Ideally, I want not to rely on users to install plugins for a really basic hook to run, namely a simple test. Is this possible?
You can use bazaar server and install hooks on them.
also You may find interested next links:
http://people.samba.org/bzr/jelmer/bzr-shell-hooks/trunk/
http://bazaar.launchpad.net/~stianse/%2Bjunk/bzr-shell-hooks/
I did some research into this and found motivation behind the lack of branch-specific hooks in distributed revision control systems. I had compared to Subversion, a centralized RCS, as an example of the desired feature.
GIT and Mercurial are distributed RCSs (like Bazaar) that have tools for hooks, including different approaches to branch-specific hooks and global hooks. Regardless, the hooks are not revision controlled and they require the user of the branch to enable them due to the security risk. In the Mercurial documentation on hooks, under the section titled "Hooks and security," it says:
In Mercurial, hooks are not revision
controlled, and do not propagate when
you clone, or pull from, a repository.
The reason for this is simple: a hook
is a completely arbitrary piece of
executable code. It runs under your
user identity, with your privilege
level, on your machine.
It would be extremely reckless for any
distributed revision control system to
implement revision-controlled hooks,
as this would offer an easily
exploitable way to subvert the
accounts of users of the revision
control system.
In a centralized RCS, like Subversion, the hooks are run on the repository server, so user permissions and server-setup restrict the impact of a damaging hook script. In a distributed RCS, the hooks are typically run on the user's local machine, which is risky.
As vitaly.v.ch mentions, a Bazaar server could be setup to run hooks when pushed to and pulled from. But then a pre-commit hook doesn't make sense, since the commits happen on the user's machine. It would then be more like a pre-push hook.
Bazaar has all the needed functionality for hooks, but individual user configuration is required to install and enable them due to the security risk they pose.
No, your users have to install the plugin to activate your hook.
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.