When we talk about development environment, that could mean many things. There is the physical environment of where design and programming is done; the software tools that are used develop the application; and the environment where applications are deployed and consumed.
Our main Coldfusion environments consist of a development server, test server, and production. The development server points to a development database. We have full access to the file structure of the file share, but not the root CF folders. And we mostly have full access to the development database. We can create, insert, update, delete nearly anything on the Oracle development instance. While we can go to the DBAs an ask for a table to be created or procedure written, we typically do that work ourselves. Not only does this paradigm make for an efficient development cylce, it also forces us to be intimate with the data and database structures that are being consumed by the application. That said, if we are modifying anything in the ERP system, we generally defer to the DBAs.
We don't have a deployment schedule. Typically, once a project has been completed, demonstrated and tested, it gets deployed. When a new application is deployed, it gets first priority in support. Over time, as the application matures, it will get yearly updates based on user feedback or requirements. If the application technology structure is outdated, as in the TRIPS application, it will be scheduled for a rewrite.
So, does all this sound normal? Perhaps exceptional in a good or bad way? Too much detail? Not enough? I'm new a blogging and like to know.
Cheers!
Organizational
My employer is a small college in Pennsylvania with about 2400 four-year liberal arts students. Our main job is to support the administrative staff and faculty by building custom applications that fill gaps in regard to the ERP system used on campus. My position as Senior Application Developer falls within Enterprise Systems under Library and Information Services. As far as developers are concerned, there is just me, my boss (half a developer) and one Application Developer. When our department is fully staffed there are 15 people: 1 Director, 3 Associate Directors, 2 developers, 2 DBAs, 2 business analysts, 2 Application Administrators, and 3 project coordinators who interface with the functional areas of the school. This paradigm has been in place for the past 11 years and has seen little turnover. The collective experience and institutional knowledge of just the developers is about 36 years. This amount experience makes project planning and decision making very efficient.
Phyiscal
One can tell the college is older by looking at the large traditional limestone buildings. My office is in a building built in the 1950's that I believe was initially constructed as (what we would call now) a union building. Now, it houses our infrastructure team on the first floor, and the Enterprise Systems team on the second floor of which I am part of.
Having worked in a cubicle at my prior job, I am very fortunate and appreciative of having a two window (yes two windows) office. It's generally very quiet here, almost to a fault. We have a newly remodeled conference room at the end of hall to conduct meetings and demo software.
In my office, I have a large desk with plenty of work space and storage. And on that desk sits a Dell PC with a solid state drive (highly recommend a SSD) and three monitors. I also have a Mac on the book case which is generally used for testing. While most of our users have PCs, quite a few have Macs, especially with regard to the faculty. I also have a Surface Pro which is intended for traveling which I rarely do.
I don't share this to brag - I am quite sure many developers have a physical space that far exceeds mine. I share this because this environment makes my job much easier. It's quiet with only periodic disturbances. There is immediate access to technical decision makers and the customer is only a direct phone call away. Most days are productive unlike the blinds that had just one job. Facilities!
Development, Deploy, and Consume
We are fairly flexible in our decisions as to how we develop and what technologies we use as long as they are inexpensive, stable, and produce a functional product. Coldfusion is the backbone of our data interface to the Oracle databases. CF, in some areas, is used heavily on the front end as well. But any new development will utilize AngularJS or Angular.
Most of my day is spent in ATOM.IO. I've found it to meet my needs with regard to editing. I have used Eclipse in the past as well as Dreamweaver and Flexbuilder. For the database interface we use Toad. I'm not particular fond of it, but there really isn't much out there. My browser of choice is Google Chrome. The college has moved to Office 365, but we don't do any development for that platform (yet).
For styling web pages, Bootstrap 3.0 is used. I would eventually get to 4.0, but that would required some serious time to implement. And at that point, there may something shinier like Materialize. We of course utilize jQuery in our portal framework (more on that later), and have a sundry of AngularJS plugins and such.
We currently don't utilize any GIT repositories. That may change in the future, but with just two developers who typically don't overlap on projects, it seems unnecessary. That said, I have deployed stuff with big "ahhh - roll it back" moments. Because there are just two and half of us, we have a lot of access and leeway to files and servers that we probably wouldn't have in a larger environment.
Our main Coldfusion environments consist of a development server, test server, and production. The development server points to a development database. We have full access to the file structure of the file share, but not the root CF folders. And we mostly have full access to the development database. We can create, insert, update, delete nearly anything on the Oracle development instance. While we can go to the DBAs an ask for a table to be created or procedure written, we typically do that work ourselves. Not only does this paradigm make for an efficient development cylce, it also forces us to be intimate with the data and database structures that are being consumed by the application. That said, if we are modifying anything in the ERP system, we generally defer to the DBAs.
We don't have a deployment schedule. Typically, once a project has been completed, demonstrated and tested, it gets deployed. When a new application is deployed, it gets first priority in support. Over time, as the application matures, it will get yearly updates based on user feedback or requirements. If the application technology structure is outdated, as in the TRIPS application, it will be scheduled for a rewrite.
So, does all this sound normal? Perhaps exceptional in a good or bad way? Too much detail? Not enough? I'm new a blogging and like to know.
Cheers!
Comments
Post a Comment