Version Control & Deployment

[evu]

Hi,

I’ve had a little experience with Git on a personal level, mainly to get to grips with it. In this case I had a local WP installation set up on ampps, I’d make changes and when I was happy I’d push the changes to Bitbucket and FTPloy would deploy them to my live server. No problem, simple enough.

Now, the question is, how does this work for a large ecommerce site? At work we have a dev server and the live server. At the momement, we simply use FTP to try things on the Dev server and when it’s signed off, it just gets manually FTP’d to the live server. What I’m confused about is how do you try things if I don’t have a local server set up?

I had planned on getting it set up so that things are pushed to the dev server, once it’s signed off it gets merged with the live server code base and pushed to the live server. I don’t understand how this works though, do I have to push/commit everything I want to try whilst developing to the dev server? That’s a lot of hassle…

How do you manage such a use case?

[Alen]

What I’m confused about is how do you try things if I don’t have a local server set up?

You need to replicate the production server environment locally. Matching your development setup to production as closely as possible is paramount.

There are few things that can help you with this. I use Vagrant to manage my servers locally.

You’ll need:
– Oracle VM VirtualBox
– Vagrant
– Vaprobash – Ubuntu 14.04LTS – 12.04LTS, used for provisioning. If you need OpenSUSE or similar look here.

This might help as well.
– Servers for Hackers
– Get off MAMP a Laracast video.

Hope that helps.

-Alen

[__]

do I have to push/commit everything I want to try whilst developing to the dev server?

If you want to test it there, yes. As Alen says, it’s better to set up a local dev environment as well. My git workflow is like this:

• do local work; commit
• test
• when ready, push to dev site (testing site on production server)
• test
• when ready, pull from dev site to live site.

[nixnerd]

do local work; commit
test
when ready, push to dev site (testing site on production server)
test
when ready, pull from dev site to live site.

This is the workflow I’d recommend as well with one addition. Depending on the project, there is something to be gained from pushing it to Github at some point in the workflow.

I generally make commits, then when I’m happy I push it to Github. This allows me to collaborate with others, use a built-in issue tracker, see in-line diffs, etc. In your case, you could continue to use Bit Bucket or Gitorious or Git Lab. Github is just so awesome though.

After that, I pull to a remote test environment, then pull to live production environment. These are not different servers… just different containers.

But yeah, that’s basically the way to do it.

[nixnerd]

You can also use hooks with Git to automate some of this… I don’t but you can.

[__]

there is something to be gained from pushing it to Github at some point in the workflow.

“Github”, in this context, expands to “Github or another (possibly self-hosted) remote repo.”

[nixnerd]

“Github”, in this context, expands to “Github or another (possibly self-hosted) remote repo.”

That’s why I said this:

In your case, you could continue to use Bit Bucket or Gitorious or Git Lab. Github is just so awesome though.

I just said “Github” because it’s what I use for all my projects and it’s the one I’m most familiar with. I briefly toyed with the idea of hosting my own repos with Git Lab… but decided against it.

I think it goes without saying that Github is BY FAR the best for social purposes. If you code with other people or want to open source a repo… Github is the way to go.

But… if you want unlimited private repos for free, use another tool.

Sorry for the confusion.

[Alen]

I don’t think the issue is with version control, it’s more of can OP try new things out on his/her own without breaking staging/live server. Team is using FTP. But OP wants to leverage benefits of versioning while working on his part.

[__]

Sorry, I didn’t mean to contradict you. Yes, you did say that. I just wanted to point out (explicitly) that the remote doesn’t need to be a third-party service —you can use your own repo on your own server as well.

I also agree that github is a very, very useful tool. Sorry for the confusion!

[nixnerd]

No problem. It is good to point out you can use whatever Git service you want… or NONE AT ALL! You could just use Git. But, you lose out on some of the other stuff.

Team is using FTP.

I talk to other devs WEEKLY that don’t use version control at their shop. They just roll with straight up FTP for teams of 5-10. It’s just simply amazing that they don’t experience more disaster.

I’m working on a REALLY simple framework right now. I could absolutely do without version control… but I’m too scared :)

[evu]

Thanks for the replies guys.

Yeah the thing is that because the platform we use isn’t entirely managed by us, it’s impossible to have a local version on my machine. A third party provides the platform as a service and manages the heavy back-end stuff and the CMS. Think MagentoGo but with access to the HTML templates(smarty), css and js. It’s very surprising a company as big as this doesn’t use version control already to be honest…

From what I’ve found elsewhere, it doesn’t seem like version control is viable on this set up, which sux, especially when there’s multiple people, including freelancers, working on the site…

Obstacle after obstacle here :(

[nixnerd]

You could do what someone already said and use version control all throughout the development process… then just FTP the master branch after code review. It absolutely sucks to do it that way but… “it is what it is” as they say.

Your only other option is to quit your job and just become a freelancer… which has its own set of occupational hazards :)

[nixnerd]

Is there a pitfall in that kind of workflow I’m missing? I’m assuming whoever WANTED to work locally could just do it, right?

You need to keep in mind, I don’t work with a big team. But… it seems like it would be even more important with a big team.

I develop and design in-browser with live-reload plugins. So, I code something and immediately see the result. Now, this can be done without a local server for static sites. But… the second you want to do something more interesting, you need that local server setup so you can run server-side scripts and have a database.

In my mind, there are two drawbacks to not having a local environment:

1. Time. It takes longer to upload stuff to the testing server, test, then make granular changes locally, then upload again and test again. It’s much easier to just see the change in the browser real quick and then adjust accordingly.

2. Commits. Without local test environments for all devs, you’re going to get crappier commits. The quality of the repo will suffer because changes haven’t been adequately tested locally before they were committed to the code base.

I really think everybody should at a bare minimum have a local testing environment. LEMP/LAMP/WAMP/XAMP/MAMP really aren’t that hard to set up.

[Author]

Posts