I repeat the title of the post that more that a title is a statement
AUTOMATE PROCESSES IS SAVE A LONG TIME
This is not an easy task, but one of the ways of addressing the same is as follows
1. Identify the repetitive tasks that we perform manually during the development of an application
2 Assess the possibility of creating an automated process to deal with these tasks
3 Define a period of trial for the implementation of this process
4 Verify the gained time using this process
If you follow these steps during the implementation of a process of automation, we’ll probably see one of these two options
-What initially appeared to be a task that could be quickly replaced by a script is then quite complicated and no sense abandoning the manual process
-automated process begins to be part of a process of increasing automation that helps us to gain quality in our developments
This seems a little theory of Friday night beer actually is fairly close to our day to day. Here is an example with one of the great "Gallardo Javi" (to see when create you a blog che!)
It was necessary to compress it in a special format, separate the compressed file in multiple chunks, sign them, and couple of steps more to share the output of an application.
When we did this process by hand, it took us less than a minute. But there was always the possibility of wrong put password of the ZIP, separate evil chunks, etc. Javi took 30 minutes and created a script that was responsible for this process.
In this way, we always have the same OUTPUT from a repetitive and predictable process (which is one of the bases on which we must work).
To metric level, simply avoiding Javi is wrong in the generation of a package already we had won the the script generation time. Javi is a crack, but if we assume that 2 times a day I could be wrong.
All subsequent executions gave us a profit of + 300 seconds. Finally, after a couple of months we had won 2 days/man. (This translated into €uros always gives us a joy)
With Javi not we went further, with the script us enough, but there is always the possibility of a little thinking out-of-the-box
- delegate the responsibility to carry out this process in a Team Foundation build.
- process the result of this process only occasionally successful compilation and if the tests are executed correctly
- automate the packaging and distribution from this process
When we arrived at these scenarios are closer to having Continuous Delivery scenarios (about what spoke in this link), simply automating tasks.
There are many scenarios where it can automate, most result in deployments, but quickly occur to me the following
- Deployments, for example when we deploy to AZURE, are why it doing always manually?
- Tests, the main point where automate guarantees us quality
- Code generation, is not one of the most recommended, but work with templates for example is a way to always ensure the same OUTPUT from a given INPUT
- Many more…
Finally, discuss the best time where we can apply these processes is perhaps in time to integrate our code. In the case of working with Team Foundation, the definition of a build is incredibly powerful to implement these processes.
AVANADE Spain we have a number of Build definitions that allow us to perform different tasks of automation. From processes to ensure the quality, as the execution of analysis of coding style (StyleCop), generation of custom reports based on unit testing and testing of MTM, until deployments automated AZURE, ClickOnce, WebDeploy, etc.
Saludos @ Home