One company, one work’s infrastructure III
Jul/091
Continued One company, one work’s infrastructure II.
And One company, one work’s infrastructure.
Well, but what happen if we haven’t a sysadmin department?
There are many other ways to create a work0s infrastructure. If you don’t have a sysadmin dep and want to use these techniques, you can do as follows.
First, we will assume that don’t have control or directly don’t have DNS & DCHP services. Then all employees have to be their own sysadmin.
When arrive a new developer they have to configure her own Apache server, checkout the projects and configure her own host server to associate projects with ips. Something like this:
127.0.0.1 project1 project2 …
It’s so easy, but “require“1 a strict nomeclature to document and teach to developers. And, in last instance, developer do it correctly, because there is no way to verify it.
If all is ok, you can change your own host file with all dev and project to check dev front-end.
Pros:
- So easy and so flexible.
- Don’t need sysadmin (and possible recurrent calls for systems to solve problems).
- Don’t require maintenance.
- If you don’t create a strict nomeclature, don’t need teach it to new dev.
Cons:
- It’s so less powerfull.2
- Don’t have control of user dev structure.
- Can take problems in dev with config files or with “duplicate names”.
- The CEO have to change at hand her own host file to see the devs front-end.
Then, What is the best? What’s the best for my company? The answer is I don’t know. You can use one or other, as you want. You can mix or change them for your own company situation. Or, you can invent another infrastructure.
These are the foundations of the infrastructure:
- At least, three spare servers3
- One control version server.4
- And, if you use “user dev zone“, two ways to create user dev infrastructure.
Well, with this you have a idea of how to do. I suppose5 that in future i will teach how to check “dev job”, but if you search for “SVN utils” you can easily give a idea.
- It’s not necesary, everyone can do everything. But if you want check the job or have a simple configuration file, and many developers. Should become necessary. ↩
- Yes, you can check the source – and this is the important- but it’s no easy to check front or know in with projects are the devs ↩
- User dev zone is so recomended ↩
- I recommend SVN ↩
- I have not writte so far ↩
One company, one work’s infrastructure II
Jul/091
Continued One company, one work’s infrastructure.
Now we have a “job’s flow”, perfect. But, how can we set and use “dev” and “user dev” zones?
We assumed that “pre” and “pro” are in external hostings or at least in the DMZ1. They will be set as subdomains or domains in internet as usual
But, what happen with local domains? Here are two ways of action:
First with a sysadmin department2
This way need a sysadmin because spend more time to configure all, and maintain after. but it’s more powerfull, facility the check and the only think you need are install, configure and update the combo DHCP + DNS services and local XAMP services.
Note: I’m not a sysadmin, and I don’t know if this is the best way or how automate this. I shall be grateful if you can edit and complete this section.
The way is so easy. Install and prepare DHCP and DNS servers. DHCP will be set to use our own DNS server. When this will be ok you must configure DHCP to associate developer server with a unique IP. And DNS will be set to associate this IP to local name3
Ok, in all intranet you can see devel zone with this name, perfect. Now go with “user dev” zones.
When arrive a new “user pc” at work, sysadmin must set DHCP server to associate the ethernet mac with a single IP, and DNS to associate this IP with her own “pc name”4
So far, so easy and smooth. You can use local name to access at “devel”. And “machine name” for each pc.
And now, when arrive a new developer, sysadmin only have to associate unique user name with employee and create an alias between user and “pc name”5
Thus, the employee only has a easy couple of things to do. Configuring virtual servers of its own apache and checkout of the code for each project.
And in the intranet, you has CEO can check and control all user’s frontend easily; for example:
We uses “devel” name for developer zone, and we have only one employee with username “alquesada”.
We have two projects actives and developing: “develname1″ and “otherdevel”.
Well, if all be ok, you can see in the intranet:
| Project/Devel Zone | Developer Zone | User Devel Zone (alquesada) |
|---|---|---|
| develname1 | http://develname1.devel | http://develname1.alquesada |
| otherdevel | http://otherdevel.devel | http://otherdevel.alquesada |
- Remember that “pre” will be see by the client ↩
- Sysadmin dep may have one hundred employees, two, or just one, you as CEO ↩
- This will be “local”, “devel”, “dev”, or something else ↩
- It’s important to bring a comprehensive suite of business material. This can be easy if each PC has its own name as “develPC-130″ ↩
- This can become difficult exponentially with the number of employees. This is where the sysadmin will look and claim their range. ↩
One company, one work’s infrastructure
Jul/094
Well, I was working in many develop’s companies since now. And the first thing I learned is:
“Whitout a unique, static, strict and complete work’s infrastructure is imposible that your company grow up.”
The employee came in and come out, but the code stay here, at company.
Think a new employee that arrive at company. Whitout a work’s infrastructure, this person will develop in her computer, use google source to save you source or directly, will writte source in production. Then, some time before, the developer go out; And you, as CEO, will have a problem.
What this person has done so far? How many things has he changed? And where?
Then, the only solution is spend the time of your new developer only to check all the source’s status.
Note: How said in Spain: “Cada maestrillo tiene su librillo” This isn’t the panacea. Only some tips to unify infrastructure, or simples ideas for everyone.
First: Spare and Control
Spare your jobs in three or four states.
- [own developer zone] This isn’t necesary, but soo recomended. All developer have here her own zone to develop and check her own source. Usually, this zones stay in developer’s PC.
- Develop zone. How it said, it’s the only zone where is “allowed” write code. If any change have to do, this must be do in this zone.
- Preproduction zone. When one step has been done and check, then it “go up” to preproduction zone. This zone can be see for the client. To check, change or approve the project’s steps. The only think that you have to do here is change the config parameters acording to preproduction system.
- At last, Production zone. Here, only source’s updates and config changes are “allowed”. This are been seeing to all internet, and errors here “can’t existis”1.
Note: It’s recomended that all states stay in diferent machines. What will be happen if a bug into developer zone kill the apache’s server?
Ok, but how control this new job’s flow?
Well, this is too simply with a version control system. Like Subversion (SVN) or Concurrent Versions System (CVS)2. This server will be in other or in dev3 machine.
This services take the control for you of the updates, commits, merges,… Only job in “dev” (or user’s dev) zone, where you can commit, and update the “pre” or “pro” zones with this sources. It’s so simply and have so much power.
This is only the first step. I will writte two or three more post to splain this and powered it.
