Automating your development process

Automating the development process as much as possible is quite common in larger teams where they have time and resources to implement it without slowing the development of the application.

When you are working as a single developer or in a small team you might recognise the benefits provided by CI and other automation tools but choose to not implement it due to pressure to show progress developing the project.

I’d like to share a little of my experience working with and without CI and then I will talk a little about what else can be done to help you out.

The first project I worked on in an enterprise was a MVC .Net application. We had Visual Studio, Re-Sharper, Style Cop and TFS Build Controllers set up for us. At that time I started on the project as a entry level programmer and all this was set up for us. Re-Sharper combined with Style Cop helped keep our code well structured and inline with conventions set out by the senior developers. TFS allowed us to manage our code and deploy successful builds to our cloud server that could be used be used to demo and test new features.

Due to changes in the organisation, the senior developers who were on the team moved on to new contracts and I was moved to new projects with very short deadlines. There were only 2 developers on this team including myself. Both of us had a similar level of experience and had never set up any sort of automated development environment. The projects we were working on were being managed by engineers who could code but they were not software developers and not aware of development practices. Each project had a tight timeline and people wanted to see results quickly. Due to our in experience we caved into pressure and started developing straight away rather than taking the time to set up a proper development environment. Soon after we started developing, we noticed that we weren’t as productive and code reviews were highlighting a lot of mistakes. We hadn’t had Re-Sharper set up and we started to miss some of it’s productivity features. We requested licences for it and installed it, and noticed an improvement in our productivity and there were less issues in code reviews straight away.

Everything was going ok for a while until we came to the end of the project. So far our demos had involved sharing our screen and showing the product owner the application working, the owner had never used the new features. We wanted to move the code base to a test server to allow the owner to test the application. We had the server set up already from the previous version of the application but it was a very manual process deploying the code. We were using the Publish feature of Visual Studio. When we moved the code over for the owner to test. This was his first time using the new features, straight away he found parts that he didn’t like and asked us to rework some of the features on the application. If we had CI set up the owner could have been testing features as we developed and giving us quick feedback. It would also have allowed us to deploy our code quicker with no manual effort.

Nothing I have said here is new or groundbreaking, I knew the benefits of automation and best practices with agile development, but due to my inexperience and eagerness to please management we didn’t follow what we knew were best practices. This put a lot of pressure on us as our workload increased and we were struggling to keep up as we were asked to work on a second project at the same time. The point I want to make is take the time at the start of a project to get your environment setup correctly. I think this is extremely important even in small teams. Even though we knew better we still fell into the trap and paid the price later on.

My next couple of posts will be about how to set up a good environment. I will be concentrating on setting up an environment that can be used with multiple languages. The reason for this is that I like to experiment with different languages and write applications. I want to have a development environment that is the same no matter what language I want to use so I can concentrate on learning the language and developing an application. I don’t want to spend time setting up a new automation environment for a new language or project.

I’m going to look at this from 2 points of view. The first will be the compiled language C# and then I will look at it from Ruby which is a just in time language. The main feature I will be looking at that I think will provide the most value are

  • CI with Gated check-ins
  • Source Control
  • Displaying the health of the project
    • Test Coverage
    • Passing Tests
  • Clean and well formatted code

After that I will look at what other integrations can be included, and how to automate code reviews as much as possible.

Leave a Comment

Your email address will not be published. Required fields are marked *