This simple trick allows to retrieve GIT_ROOT or PROJECT_ROOT from anywhere within the project folder structure. Whenever it’s needed, just use this:
export GIT_ROOT=$(realpath $(git rev-parse --git-dir)/..)
cd $GIT_ROOT;
Archives for : git
Underlying systems and processes
Welcome back to Measure9 blog. Here I continue with article series “Setting up Magento development environment, step by step“. Please read Part 1, too. In this post I’m going to shed some light to surrounding processes and most low level tools. So we go from general to more specific with each subsequent article in this series.
Development process
A quite generic Magento Development Process looks like that. It involves an Issue Tracking System (ITS) and Version Control System (VCS). Also unit testing is in place. If you’re really after quality and fun in development then I do recommend to set up Continuous Integration solution. There is quite a number of solution like Bamboo, Jenkins and others.
Version control process
Version control is something that should be in place even if you’re working alone. It helps you to keep your work organised, establish good working habits and integrate your work thru various environments and phases of a project’s lifecycle.
There is a number of Version Control Systems available. To name a few that you already may have heard of:
- GIT
- Subversion
- Mercurial
- CVS
- ClearCase
See more from Wikipedia. The first 3 are quite modern while CVS is an old dinosaur and ClearCase is a proprietary yet very powerful and integrated system by IBM. Anyway, my gut feeling says that GIT is most widely used nowadays and there are reasons for that.
GIT is
- distributed – you can work offline and still keep stuff under control
- fast – I mean it’s really fast:)
- easy to use, supports easy branching and merging
- last but not least – invented by Linus “The Linux Guy” Torvalds himself. Quality…
Now about the process itself (when git is used):
Explanation from left to right:
When you start a project you do git clone (1). This gives you working folder with all project’s files. You do it once. Then, every day after your morning coffee you do git pull (2). Git pull gives you updates that have been pushed to upstream by other developers. After that you do git branch (3) if you haven’t done it already. This gives you isolated branch where you can mess around with the code any way you want. There is a number of branching strategies around, you need to choose what suits you best. There’s also a good example of a successful git branching model. Now you’re working with the code and you do git commit (4) (save code version to git). It’s recommended to keep commits small, I’d say atomic. Minimum one commit per fix or per issue from the ITS or per file. You’ll see that it’s good to keep commits small because when they day of rollback comes (and it will!) then you’d be grateful you did small commits that can be rolled back one by one. Then you feel that you’re ready to share your work with others. So you do git pull (5) again to retrieve latest changes from the remote and master branch. Then you merge (6) master branch into your named branch and if it’s cool (no merging errors) you’ll merge your changes back to master. Then you do git push (7) and share your work with others.
Some day (when I have time) I’ll add command line examples here, too.
Choosing hardware and installing operating system
Magento is a resource hog and thus good development hardware is a must. I’m personally using Macbook Air that has SSD permanent storage. It’s fast but standard MB Airs have only 4 gigs memory that is too little:( So you better get yourself a machine with following specs:
- >= 8 GB RAM
- >=128 GB SSD disk
- A good (dual head) video card (for dual monitors)
- A good keyboard
- A mouse
- A pair of good speakers (in case you’re working in your own room;))
Operating system
OSX and Linux are both good choices for Magento (or any web) development. For OSX there’s excellent package manager homebrew that gives you all necessary tools if you’re not satisfied with already built-in Apache web server and somewhat oldish PHP 5.3.
With Linux it’s simple – choose a distro that you like. My recommendation is Ubuntu or Debian. The both have APT package manager that satisfies all your needs.
Installation and configuration of tools will be covered in future posts.
Command line, Terminal application
One more thing is the terminal application. I think the the Linux’ defaults are good but there’s a better alternative for OSX’ Terminal.app and this is iTerm2. Install and use this one instead of native Terminal.app. It provides a few very good convenience functions like “copy when select” and similar.
Background
Magento solutions get bigger and more complex, at least here at Eepohs. Magento development requires multiple displines like Frontend Development (JS, CSS, HTML, XML etc), Backend Development (PHP, JS, XML etc), System Integration (JSON, XML, REST, SOAP, (s)FTP etc…). So it’s quite obvious that Magento development is rather teamwork than a play of single freelancers. Freelancers can take your solution to some limit but sooner or later you need to hire a team that can support solution and take it further on.
Tools
There are a couple of tools that are crucial for teamwork and especially important when your team is not sitting together but is distributed in the room and possibly in time also. The tools for successful teamwork are:
– issue management tool – JIRA
– version control tool – GIT
When you have more than 1 developer you need a process. In fact you’d need a process when you’re working alone, too but it’s not that stringent in this case.
You have several processes while doing development:
– version control process and strategy
– issue management process
– general workflow
– development itself – writing code, chasing bugs, debugging etc.
– quality assurance (QA)
– deployment process
You have several processes while doing development:
– version control process and strategy
– issue management process
– general workflow
– development itself – writing code, chasing bugs, debugging etc.
– quality assurance (QA)
– deployment process
The latter seems to be quite tough because there’s a lot to be deployed between different stages and instances.
There are 4 stages (and n different Magento instances in each) in Magento development cycle
– development (local developer machine, local server)
– testing (internal testing by the QA team)
– staging or pre-live (pre-live testing by the QA team and the customer)
– live
 |
| Deployment of changes |
A note about popular alternative – Subversion
Subversion is not good for Magento development for 2 reasons:
- it must be connected to central server. So you cannot version your files while working offline
- svn creates its own special control folder .svn with a lot of extra files inside every folder in Magento. Magento codebase is huge and svn creates a very big extra overhead for your filesystem. It makes it painfully slow and tedious.
- … I won’t start rant about merging in svn and git here…:)
- And yes – I have used svn, A LOT. So I know what I’m talking about:)
Magento specific issues a.k.a the Bad News
Attribute sets and attributes
How to manage attribute set and attribute migration between 4 stages described above?
The 2 above are actually quite simple to resolve. Magento offers excellent tools for that – install/update scripts. Just add your attributes and sets via install/update scripts and they will get to all environments automatically when code is deployed there.
Stores and Content
Store is the most crucial entity. Everything is depending on that, even configuration and content.
Configuration
That’s a tough one. How to version configuration? How to move conf changes from one Magento to the other?
Magento Deployment tools a.k.a the Good News
There’s a cure for all these issues above, though… I’ll shed some light to available tools in the upcoming posts.
