I disagree. Here's the link: http://aspose.com/file-tools
I hadn't been here for fifteen years
I hadn't been here for fifteen years
Alex Lieb wrote:
Coworker thinks there's a security issue with that; he says if someone hacks our git server they could tell it to push from the remote repo to the production server's local repo. I know you can push from remote repositories to local repositories if you really want, but I can't tell if that's actually a security issue we should be concerned about.
I hadn't been here for fifteen years
I feel like it would be cool if we could make a local repo on our production server that has the ability to pull from the remote repo. We'd have a master branch to store the latest stable copy of the site, and when we're ready to actually update the site we could push to the master branch from one of our machines, then use a remote git command from within the office to tell the server to pull from that branch directly onto the server.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Sorry, Jayesh. Most places I've worked, the auditors would nail our hides to the wall if we allowed developers to produce modules directly to production.
Tim Holloway wrote:
A lot of shops, there are actual source code mods that have to be made because the artefact has direct references to test or production DBMS's and so forth. Myself, I have a strict policy that the development, test, and production versions should be byte-for-byte equivalent (if not 100% identical), and so I inject the environmental differences from outside (for example, using JNDI for webapps). Despite that, however, the actual production builds would be made by production personnel, not developers.
What we'd generally do would be to maintain a development archive, then when a project was ready to go live, we'd commit the source changes and pass on the specific version info form that set of changes. Production would then merge that into the official production source archive, run the build, and deploy it.
Of course, to make that all work smoothly, you need proper planning and infrastructure. Since the operations staff aren't expected to be very development-savvy, that means that you'd want to use generic build and packaging systems (for example, maven and RPM) and keep explicit instructions in the change plan. A build control system with a dashboard (such as Jenkins) is a useful thing to have as well.
I disagree. Here's the link: http://aspose.com/file-tools
Jayesh A Lalwani wrote:No, there's only one correct way of doing this. Go look up any book on CCM practices and/or Continious delivery practices, they will tell you this
I disagree. Here's the link: http://aspose.com/file-tools
Don't get me started about those stupid light bulbs. |