• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Using Github to Help Deploy Production Site?

 
Ranch Hand
Posts: 66
3
Netbeans IDE Notepad Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

I work at a place that just recently put together a git server and made repos for various projects associated with our company website. We're trying to work out how we can/should use it to help with deploying changes to the live site in the future.

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.

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.

If someone could do that, it would mean they would already have remote terminal access to the servers that house all of our git repositories and it would mean they would have one of our git credentials. Is this a valid security concern, and if so, is there any better (but still secure) way to push to production than just moving the files manually and telling the server to redeploy manually afterwards?
 
Ranch Hand
Posts: 417
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

We recently moved from CVS to git and one of my coworker recommended to install gitlab.

I gave it a shot and I never looked back.

Nice html based management interface on top of git. I installed turnkeylinux image in a VM and that was it. The git repositories files are actually on SAN so I had to tweak a little.

You may install gitlab from scratch if you have more budget.

And yes, you can push to whatever repository you want with git although we don't push our company code to cloud hosted, publicly accessible, repositories.

I would recommend that you configure your firewall to allow the prod server to pull from your company owned repository.

Also, don't forget a proper backup startegy.

 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From a security perspective, I always consider the prod server less secure than our own repository server, a lot more insecure so, maybe your co-workers have a point.

You could:
1) set up a repository on the prod server if feasible.
2) push to the repository on the prod server
3) have the prod server pull from its local repository.

But in the end, I consider the most secure way is just to package applications as war files and to deploy them on the server. That's what we do.

You never know what kind of classified data might end up in a git repository considering it keeps history.

So, I guess your co-workers are right ;-)



 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



It's the other way around. If your prod server is considered more secure than your in house git repository, than you are in trouble.

Similarly, your backup server should be considered much more secure than your prod server and the backup server is the one that knows how to connect to the prod server.
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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.



Warning! Danger, Will Robinson, Danger! The road to hell is paved with good intentions, and many well meaning people have walked this path to find themselves in the same hell

Your intentions are good. You want to automate deployment of the most stable version of your software into production. That is good. In the industry this is called as Continious Deployment. Automating deployment is one of the cornerstones., However, this is what people have find out.. and security has nothing to do with it. It's always a bad idea to promote source between development, test and production. You should be promoting "artifacts". What this means is that instead of building a WAR for your application on dev, then rebuilding for test, then rebuilding for prod, you should build it once, and then move the WAR from dev to test to production.

Why? Because you want to make sure the actual files that gets deployed into prod (aka artifacts) get vetted in dev and test before they move to prod. If you have seperate processes for building prod and test, then there is a distinct possibility that they will go out of sync. This means that you will find bugs in production, and I guess you don't want that. This is why you should have an Artifact repository, which is seperate from your source repository. You build your artifacts once and then promote them in your artifact repository.

Continious Delivery is a very rich topic that really everyone in the industry should start learning. A lot of people stumble because they don't bother learning about it. There is a company called Thoughtworks, who is doing some good work on it, and publishing books on it. You can find the book here An Thoghtworks architect , by the name of Neal Ford. has a video training series here that is mostly free. It's a good introductory course. You might want to look at it.
 
Saloon Keeper
Posts: 21249
137
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

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.
 
Jayesh A Lalwani
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Obviously, for someone who is contemplating deploying to production right from their source repository, this is not a concern


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.



All of these touch on some very good Continious Deliver principles and techniques, and the resources I linked to goes in depth about these
 
Alex Lieb
Ranch Hand
Posts: 66
3
Netbeans IDE Notepad Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey! So in the end we basically decided not to change anything. Basically it was determined that having the live site connected to the repo in any way would be a bad idea for a number of reasons, and the benefits wouldn't really be proportionate to the detriments.

We're a really small shop. We don't deploy new versions of the site very often, so there really isn't much we could gain by automating the process. Also, if we had our production server and our git server linked like that, we wouldn't really be decreasing the overall security level, but if anyone got into *either one of them*, they would then be able to see and change the contents of *both* of them. I didn't realize the answer to this question would be so varied though; I was thinking there would be some pretty consistent standards set up for how to do this; either "Yes, you should link it to a git repo" or "God no, what are you thinking?" but what I'm gathering is while having a project linked to a git repo *can* be a security risk, which path is best is heavily dependent on the context of your specific project and how much difference you want to allow between development, test, and production versions.

Thanks for your answers!
 
Jayesh A Lalwani
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

1) Build the code in a manner that puts environment specific properties in an external file, or in external resources like JNDI
2) Deploy it to your QA and Dev environments. In those environments, set the environment properties to the values that apply to the environment
3) Test the code
4) Once code has been tested, take the war/jar/ear built in step 1 and deploy without changing it to your production environment
5) Update the environment properties in production to values that apply to the environment

Whether you automate this or do it manually is upto you. The idea that there should be one golden artifact that gets blessed by the QA process and goes into production without any change is the cornerstone of any CCM practice. There is no controversy around this.
 
Alex Lieb
Ranch Hand
Posts: 66
3
Netbeans IDE Notepad Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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



Based on what I'm seeing in this thread there is disagreement over the specific thing I was asking about. I understand your 5 step process; 4 of those steps are more or less non-negotiable, and although there's multiple ways to do step 4 they all amount to the same thing. I'm not talking about any of those steps though. Those are assumed.

All I was asking about was if it was a good idea to try to streamline this process somehow by making it a git repo and just pulling/pushing from somewhere. Based on what I'm seeing, doing that would make it difficult to ensure that you're really going through all five of those steps, but apparently some people do it anyway? So there is disagreement in this thread over whether that's acceptable practice. The course of action we took aligns with your position. My reason for pointing out that there was disagreement over certain elements was so I could acknowledge all of the arguments presented as valid while stating that none of the other solutions presented are suitable for our particular needs.
 
Jayesh A Lalwani
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me put it this way: The "disagreement" is between a person who gets paid to improve software processes, and has been a contributing member of this board for 10 years and another member who has been kicked out of the board for presenting wrong information in multiple forums. If you want to give equal weight to both opinions, then it's your loss. I have bridge to sell. You want to buy it?

Software development is not a democracy. Just because 2 people say conflicting opinions doesn't mean that they are equally valid. You need to understand the analysis behind opinion. I have given you a pretty detailed explanation of why it is a bad idea to push artifacts right from your repo into production. The other guy has said "Sure, I did it. you can do it too!"
 
Your mind is under my control .... your will is now mine .... read this tiny ad
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!